Would someone please explain the actual goings-on relating to "stopping" the HCE game via setting to Zero Sec time compression and via the "Pause" menu item?

 

In particular:

1. Do these methods have any different effects on the game?

2. Do they affect other system resources differently?

3. Does the game continue to "run" in any way that is significant to game events while in either of these "stopped" modes?

4. Is there anything else relating to the use of these "stop" methods that might be useful for the player to know about?

 

 

I'm also curious if there is any other means for "stopping" the game in some effectively paused and resumable state (other than saving the game), and if so, how it compares to these other methods, as far as effects on the game and on system resources.

 

I'm also curious what happens to the game action, and to the system resources, when the app's window is minimized, either with or without first "pausing" the game in some way.

 

These questions all came up as the result of noticing that the sound effects sometimes continue even after the game has been paused, so I was wondering what actually goes on when the game is in one of these "stopped" states.

 

Thanks.

The "Pause" menu item/ Ctrl p has no effect on the game. This is the same as minimizing the game window (which pauses the game).

 

Time compression set to zero:

1. The game does not progress as commands are entered by the player but you may see the map refresh in response to some commands.

2. Obviously you can still enter commands.

3. It is unclear whether certain combinations of commands negatively affect the operation of the game in this mode since it opens up the possibility of doing things that just aren't plausible with the game clock running (entering multiple overlapping commands for instance). My advice would be to not give commands when time compression is set to zero but I know many players do give commands without negative impact.

 

Depending upon which build of the game you are using minimizing the game either monopolizes the CPU or nicely uses next to none (more recent builds doing the latter, earlier builds the former, see ReleaseNotes.txt for detail on what version that changed). Similarly using "Pause" used to monopolize the CPU and now it doesn't.

 

Most of the sound playing is accomplished via a general windows API call and as you've found will finish on its own no matter the game state, that is not an indicator of the AI preparing its next attach, it is just an artifact of how that Windows API call works.

The "Pause" menu item/ Ctrl p has no effect on the game. This is the same as minimizing the game window (which pauses the game).

 

Time compression set to zero:

1. The game does not progress as commands are entered by the player but you may see the map refresh in response to some commands.

2. Obviously you can still enter commands.

3. It is unclear whether certain combinations of commands negatively affect the operation of the game in this mode since it opens up the possibility of doing things that just aren't plausible with the game clock running (entering multiple overlapping commands for instance). My advice would be to not give commands when time compression is set to zero but I know many players do give commands without negative impact.

 

Depending upon which build of the game you are using minimizing the game either monopolizes the CPU or nicely uses next to none (more recent builds doing the latter, earlier builds the former, see ReleaseNotes.txt for detail on what version that changed). Similarly using "Pause" used to monopolize the CPU and now it doesn't.

 

Most of the sound playing is accomplished via a general windows API call and as you've found will finish on its own no matter the game state, that is not an indicator of the AI preparing its next attach, it is just an artifact of how that Windows API call works.

Thanks for the info.

 

In my own case, I typically refrain from issuing more than one order while the game is at Zero time - and if I wish to issue additional orders, I set the time to 1 Sec, and then back to 0 Sec, after each command, assuming that will allow it to be processed - and also offering other benefits, such as updating Ready Aircraft displays, etc.

 

Beyond my simple curiousity about all this, my concern was whether there are any circumstances where tweeking the time compression back and forth to zero, or setting the pause states, could screw up the game state - because I tend to do a lot of that during the course of playing a scenario (along with a fair number of re-loads of the latest auto-save, in some cases), and so it occurred to me that something might be happening as the result of my doing these things frequently, that could lead to some of the anomalies that I encounter. Note that I typically leave the game app active, but paused, at all times when I'm not actively playing, except at the end of a game, at which time, I exit and then re-start the game app.

 

While I think of it, every so often (and always while the Game is in a dormant state), Windows will decide that it needs to adjust the virtual memory resources. I don't see any overt effects on the game, but I wonder if that happening while the game is dormant could corrupt the game's memory in some subtle way. It's unclear just what is causing this adjustment of virtual memory to occur so often, considering that the machine has only the exact same set of apps active 95% of the time (assuming, of course, that some unnoticed system tasks aren't getting wierd from time to time). Anyway, I wonder whether the Virtual Memory manager is doing right by the game during all this.

That all depends upon whether Microsoft's memory manager is bug free or not.

 

There is no harm in the method you describe to change time compression. The game mechanics as described elsewhere care not whether you are running at 1800:1 time compression or 1:1, it processes every game second just the same.

That all depends upon whether Microsoft's memory manager is bug free or not.

Well, it is Microsoft...

 

There is no harm in the method you describe to change time compression. The game mechanics as described elsewhere care not whether you are running at 1800:1 time compression or 1:1, it processes every game second just the same.

OK, so my constant futzing with time compression should cause no problems. (Whew!)

 

I'm still wondering whether leaving the game dormant at all times while I'm not actively playing it might allow it to take memory hits from other (potentially errant) tasks that go on in the meantime... especially considering that the unexpected behaviors that I see generally show up only after the game has been active for quite awhile (or after re-loads of game-saves). Still, it's hard to imagine that memory hits would be consistent enough to cause only such subtle oddities, and no severe malfunctions. Anyway, I suppose it would be "safer" to exit the app when I'm not using it, but it's a whole lot less fuss to simply leave it dormant when it's not in use.