Operations while Paused

[Flabort]

Detect when you pause or unpause:

Code Select Expand

<-state not IsPaused and if
1 ->state
@OnPause
endif
<-state IsPaused not and if
0 ->state
@OnUnpause
endif

:Awake
True OperateWhilePaused
IsPaused if
1 ->state
else
0 ->state
endif

:OnPause
#Stuff

:OnUnpause
#Stuff

[knucracker]

This probably isn't intentional therefore a new feature request:
Can you change OperatesWhilePaused to be something more along the lines of it operates during pauses, except when in editmode?
It doesn't effect me but might do to others. All it does to me is make a core a tiny bit harder to select.

I can probably do that.  In the mean time you can use IsEditMode as a workaround (most likely).  "if (IsEditMode) return" at the top of your script might do the trick.

[Grayzzur]

I can track mouse position while paused, but it seemed like mouse clicks and key presses aren't registering. On closer inspection, it's the *Down commands that aren't working. GetKeyDown and GetMouseButtonDown don't register while paused. GetKey and GetMouseButton do seem to work, but for my purposes, it will require some extra code to detect the initial click and ignore the rest.

[knucracker]

Very subtle bug on my part.  It had to do with the way "speed frames" worked.  Speed frames are the extra evaluations of the game loop that happen per game frame when you are running at more than 1x speed.  I had code in place to make sure that thing like GetMouseButtonDown only return true during one game update even when running at 4x.  There was a little bug where paused evaluations always thought they were in a speed frame (except right when a game is loaded and has never been unpaused).  But, it should be all better now for the next build.

[Grayzzur]

Thanks! My workaround is... messy.

[Grayzzur]

I noticed that this is fixed in 1.73, even though you didn't mention it in the change log.

Thanks.

[knucracker]

I must have forgotten to note it... but yes it should be working now.

[Grayzzur]

"Issue" report with OperateWhilePaused + QueueMove.

I call it a bug, but some other folks I was discussing it with believe it's fine, so I'll address their viewpoint as best I can.

The issue is highlighted in the attached sample map. Both cores, when their move queue is empty, delay 30 then queue up 4 moves. When they start moving, if you pause the map, you'll see one core pauses, and the other core (with OperateWhilePaused set) continues to move until it's emptied out it's move queue before stopping.

I do not believe this is intentional. The opposing viewpoint I mention suggest that it is. I can see the benefit of allowing queue move to continue while paused if that behavior is desired. My belief is that a core should not do anything while paused unless the map author wants it to.

Map example: The turrets in Pass the Map 2 have a range finder graphic when you hover over them. It would be nice to show that graphic on hover while paused, but adding pause operation to that code causes the turrets to continue on to the next cell when you pause the game. This is why I did not add that feature to the published map.

I don't think a map author should be forced to handle all movement by themselves and avoid QueueMove to avoid that situation. Perhaps an AllowQueuedMovesWhilePaused flag that defaults to FALSE and has no effect if OperateWhilePaused is FALSE?

EDIT: Forgot to attached the sample map. Here it is.

[eduran]

Map example: The turrets in Pass the Map 2 have a range finder graphic when you hover over them. It would be nice to show that graphic on hover while paused, but adding pause operation to that code causes the turrets to continue on to the next cell when you pause the game. This is why I did not add that feature to the published map.

Even if moves didn't execute, wouldn't the turret just keep firing from its current position?

The way I see it, you have to split the code into two scripts: one that runs while paused (UI stuff like the range finder), and another one that does not run while paused (movement, targeting stuff, shooting). You can still add both scripts to a single core.

[Grayzzur]

No, you can put an "IsPaused if return endif" to stop execution of things you don't want to run while paused. I can make it do ONLY the rangefinder piece and nothing else -- but I currently have no way to stop it from continuing QueuedMoves without ABORT/CANCEL -- and then there would be a bunch of extra code to remember where I was going and re-queue the moves on Un-pause.

[knucracker]

"Intentional or not"... is there a third option?  It feels like there needs to be a third option when I don't know or remember :)

Before I even look at the code I'm gonna say bug.  Unit movement is processed in the game update function for a crpl tower (as are some other things), so that is probably getting processed.  But I do have a vague memory of attempting to make that not be the case.

I'll add this to my notepad and take a look later today along with a couple other things.

[eduran]

No, you can put an "IsPaused if return endif" to stop execution of things you don't want to run while paused.

What about timers? If you pause the game right after the turret fired, will it fire again immediately after you unpause?

I can make it do ONLY the rangefinder piece and nothing else

You could move that part to a new script and have only the range finder script run while paused. Attach both scripts to the same core and you have a turret that only operates while the game is unpaused, but with a range finder that works during pause.

[Grayzzur]

Hmm. Delays and timers seem to process while paused as well.

That's actually not a bad idea (two scripts). There would be some communication between the scripts for variables and such. Some things wouldn't be accessible to the pause script unless the main script makes them accessible. Not too big a hurdle.

Hey V, why don't you leave this one alone for now? We'll just document the current behavior and experiment with using multiple scripts for these types of units.

[Grayzzur]

The more I play with it, the more I think just having two scripts is the elegant solution here. I can control whether or not queued moves continue on in paused mode by which script I queue them in.

[knucracker]

Yeah.... I just looked at this.  I even left myself a little note about it in the comments.
I could fix it, but it would be a little tricky based on how things are structured.  It affects timers, delays, movement, and maybe another couple things.  So my comment to myself was that I was skipping the risky work and would just recommend authors to use different cores (scripts).