Is this game missing this feature???

[IronClad]

I'm new but I'm looking for the feature that plays the whole battle back so you can watch all the turns together.

[Grisha]

That feature does not currently exist in CMBO, but I believe it will be available in CMBB.

[mikeadams]

Some time in the last two months I posted a way to do it. But be warned, it is tedious and takes up a lot of disk space

[Mud]

Speaking of replays, was it ever mentioned why solo-play replays aren't repeatable (i.e. save, hit 'GO', reload, hit 'GO' yields different results)?

Seems to me that if they saved the state of whatever random number generator -- for a simple arithmetic PRNG, this normally wouldn't be many bytes -- then one could save before each 'GO' and at least watch turns unfold identically in whatever order is desired while, say, writing up an AAR or otherwise doing a post-mortem.

Unless, of course, it's deliberate -- to, say, permit reload-'GO' just as a check to see whether you got rather lucky / unlucky. Hmmm.

[Iron Duke]

IronClad eh?

Hmmmm....

[Cubbies Phan]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Mud:

Speaking of replays, was it ever mentioned why solo-play replays aren't repeatable (i.e. save, hit 'GO', reload, hit 'GO' yields different results)?

Seems to me that if they saved the state of whatever random number generator -- for a simple arithmetic PRNG, this normally wouldn't be many bytes -- then one could save before each 'GO' and at least watch turns unfold identically in whatever order is desired while, say, writing up an AAR or otherwise doing a post-mortem.

Unless, of course, it's deliberate -- to, say, permit reload-'GO' just as a check to see whether you got rather lucky / unlucky. Hmmm.<HR></BLOCKQUOTE>

Sounds like we've got a cheater here boys.

The reason why this is not possible is because it would lend itself to cheating. The very nature of PBEM format in turn sending is done in such a particular way that there can't be any cheating, because if it wasn't it would be very easy for a player to keep replaying a turn to get the results he wanted.

[Mud]

Illiterate. In case you didn't notice, I'm asking why the solo reviews aren't replayable -- not why PBEM games are. The situation now is that you CAN "save scum" in single-player, and that you CANNOT reasonably analyze results post-game from previous turns because the results may very well be quite different, especially where significant discrete outcomes (shot KOs, shot ricochets) may differ. Does this non-repeatibility strike you as good for some reason?

I have seen references here to PBEM files being large, suggesting that entire movies are being sent. Theoretically, if the PRNG state is saved (as does NOT seem to be done), "save-scumming" is prevented, not enabled (as it is now in solo). In addition, you'd be able to go back to previous saved games and review them just they way they happened before, which would be good when you're analyzing the game, AND you would save file transmission time because you wouldn't necessary need to send the movie.

Here's why.

A turn resolution must be based on rules + state + some entropy source. Because computers follow instructions literally, if a standard PRNG such as the common C library random() / srandom() functions are used, it is possible to save sufficient state that application of the rules and repeating the exact PRNG sequence must yield 100% identical results each time. The primary exception that I would see would be if CM uses multiple threads in a way that affects combat resolution as a consequence of the operating system scheduler; in this case, repeatability cannot be guaranteed without saving the entire movie because there is too much state beyond your control. Frankly, I would like to see reproducibility even for solo play, and it strikes me as what should theoretically be simple to implement even as a toggle -- depending on the nature of the entropy source.

Remember that programming instructions are basically math which must return a given output for a given input and a current state. State which is clearly being saved includes the state and orders of the map, of all units, and so forth. If the PRNG state is the sole source of randomness AND is explicitly saved -- which may mean that CM would need to use its own routines -- and the algorithms are constant (which they would be, given that they'd be in the code) then the start state and rules are fully specified.

Since this is NOT the case -- you CANNOT replay a solo saved game to study what happened, because it changes -- logic would suggest the state of the entropy source is not being preserved. Simply initialize the PRNG during game setup phase, and track state subsequently; with most, you're not supposed to reinitialize again, anyway.

The potential downsides for saving the entropy source might be

- It's impossible, because it depends on things beyond CM's control such as OS scheduling. Fine. It'd be nice to know about this, 'tho, just out of curiousity.

- You can't test the "Was I just lucky" hypothesis. Fine. If people really want that, Battlefront could leave a toggle switch to not save state, and do whatever it is they do now (initialize based on the timer, or whatever).

[wadepm]

I think we got ourselves another one of them college boys.

[Gyrene]

<BLOCKQUOTE>quote:</font><HR> Originally posted by Mud:

Snip

<HR></BLOCKQUOTE>

Mud, one of the biggest strenghts of CM is that there is a considerable amount of "**** Happens" factor programmed in; it is not suitable for the type of clinical "what if"'ing that you described and I don't know if too many people would enjoy this game as much if the results were so cut and dried and predictable as you want.

In any case, you can only save the game before any of the random numbers are generated so the reason why the turns are always different should be obvious to such a smart fella as yourself.

Gyrene

[Mud]

Gyrene, ask yourself where the random numbers came from, and realize that CM does not require the existence of a dedicated "true" entropy source. Does it have physical dice to roll? Quantum states to check? No. Many computer programs instead rely on PRNGs.

The term PRNG comes from pseudo-random number generator. Pseudo, because it's not truly random -- PRNGs just try to *look* random according to a variety of statistical tests. A typical example is the rand()/srand() combo in the C language. If you srand() with a given constant to initialize the PRNG state, and then you call rand() a few thousand times in a row, the series will look vaguely random, but it's actually not. If you srand() with the same seed (which defines initial state) and the same code (C library) on the same platform, and ask for the same number of random numbers from rand(), you'll get the exact same output every time. There are arguably superior PRNGs to most rand()/srand() implementations, but they are still fundamentally deterministic. If you know the PRNG rules, and you know the exact state, you can predict the numbers.

There's been a lot of research into generating seemingly random numbers, especially in the cryptology community as they're keenly interested in attackers being unable to deduce a sequence. For instance, there's no point in a one-time-pad if your entropy source is weak to the point where your attacker can easily get enough message traffic to predict the rest of the key bits. Do a search for "pseudo random number generator" on Google.

Or, say, read Random Numbers in C which is a a long thread on implementing PRNGs in C, complete with sample code. Note that they are all deterministic given a start state.

The reason why I say that it may not be possible to save state and implement reproducibility is that there may be another source of entropy in CM, such as if it uses multiple threads or processes and the order of execution alters the actual results. Not all entropy is derived from traditional PRNGs; old versions of PGP didn't trust PRNGs, and computed bits from the user pounding keys for a while.

[Mud]

Incidentally, here's a silly (but true) example of the difference between predicatibility and reproducibility.

Suppose I select a book from my personal library without telling you. I then count letters, and every time the count becomes prime I list the letter. When the count hits 593, I reset it to 0.

It's a strange sequence. It isn't easily predictable, by most humans anyway (a computational linguist or cryptographer with a database of human literature might do better...). And if I select a different book, the sequence will likely be rather different. But it's perfectly reproducible if I start counting at the same number, same algorithm, and the same position with the same book, if I'm an android who makes no counting errors and never loses his position. PRNGs are reproducible, and they try to be unpredictable.

[BigZergRat]

before they lock this one up let me just say; Mud, i was with you up until you got WAY off topic and started into a lengthy explanation of random number generation.

i would suggest you quit being so defensive and reread what Gyrene had to say.

one of the strengths of CMBO is that, as in war, "**** HAPPENS".

might i also suggest you keep a little thicker skin in these boards. if you want to know why then go play in the cesspool.

try to look at this game as a work in progress. its not at all perfect but with the continueing efforts of BTS it should get better.

[Michael Emrys]

Nope. Mud is right. It isn't necessary for the play of the game that the replays aren't repeatable. Just happens to be the way it got programmed. Think of it as a quirk that may get ironed out in the engine rewrite.

[Gosh, I'm starting to think of the Great Engine Rewrite as if I were a member of some cargo cult. ]

Michael

[Gyrene]

<BLOCKQUOTE>quote:</font><HR> [Gosh, I'm starting to think of the Great Engine Rewrite as if I were a member of some cargo cult. ]

Michael <HR></BLOCKQUOTE>

Krusty is coming...Krusty is coming...

Sorry Mike, there is no re-write, it's a myth. CM:ATR (Combat Mission: All The Rest) will be based on the Close Combat III game engine with liberal ResEdit tweakings by Paton_Returns plus a new color scheme.

And it will feature walking robots.

Gyrene

[Michael Emrys]

<BLOCKQUOTE>quote:</font><HR>Originally posted by Gyrene:

Krusty is coming...Krusty is coming...

Sorry Mike, there is no re-write, it's a myth. CM:ATR (Combat Mission: All The Rest) will be based on the Close Combat III game engine with liberal ResEdit tweakings by Paton_Returns plus a new color scheme.

And it will feature walking robots.

Gyrene<HR></BLOCKQUOTE>

AAAIIIIIIIIIIEEEEEEEEEEEEEE!!!!!!!!!!!!!!

:eek: :eek: :eek: :eek: :eek:

NONONONONONONO!!!

[runs over to wall and bangs head until collapses sobbing]

Michael [now where did I put my cyanide pills]