Pause all slice movement?
Moderators: marionline, SDHawk
Pause all slice movement?
Is there any way to pause slice movement done by set slice velocity, move slice to, or move slice by? I just realized that while bringing up the pause menu in my game, slices like projectiles keep moving. Hopefully there's a way to deal with this that's not too cumbersome, so people can't be like "oh hey I'm just gonna open the pause menu to dodge projectiles".
Oops, we forgot to add a "suspend slice movement" command.
And although James implemented a way to suspend a single slice (and all of its children), he didn't actually add a script command to access that feature.
Right now the only way to pause slice movement is to bring up a menu with the "Suspend gameplay & scripts" bit turned on.
And although James implemented a way to suspend a single slice (and all of its children), he didn't actually add a script command to access that feature.
Right now the only way to pause slice movement is to bring up a menu with the "Suspend gameplay & scripts" bit turned on.
Well... I bet I could add it in 5 min... GO!
EDIT: What a mess! After implementing "suspend slices" and "resume slices" I decided they would be a really bad idea since they would make forwards compatibility impossible, so I threw them away. I'm working on commands to pause and resume individual slices, but they suffer from the compatibility problem plus even more problems!
EDIT: What a mess! After implementing "suspend slices" and "resume slices" I decided they would be a really bad idea since they would make forwards compatibility impossible, so I threw them away. I'm working on commands to pause and resume individual slices, but they suffer from the compatibility problem plus even more problems!
Last edited by TMC on Mon Apr 03, 2017 5:56 am, edited 2 times in total.
Whooosh!
After thinking about it for awhile, I also had the idea of looping through all slices and doing a "if (slice is moving)" check on each if the pause menu is brought up, and if so then attach some sort of unique invisible slice to that slice, store the current velocity of the parent slice that's moving in extra data, then stopping slice movement. After the pause menu is lowered, check each slice for the unique invisible slice, set the previously moving slice's velocity to the stored extra data, then free the invisible slice.
Gee, it seemed simple in my head, but after typing it out it seems really cumbersome. Also I don't know that it would be workable for slices moving via move slice to or move slice by.
After thinking about it for awhile, I also had the idea of looping through all slices and doing a "if (slice is moving)" check on each if the pause menu is brought up, and if so then attach some sort of unique invisible slice to that slice, store the current velocity of the parent slice that's moving in extra data, then stopping slice movement. After the pause menu is lowered, check each slice for the unique invisible slice, set the previously moving slice's velocity to the stored extra data, then free the invisible slice.
Gee, it seemed simple in my head, but after typing it out it seems really cumbersome. Also I don't know that it would be workable for slices moving via move slice to or move slice by.
-
Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Firstly because I wanted to make it pause animations as well as just motions, because the two are rather intertwined (e.g. walking animations), but that would be a big break when NPC and hero walking (and maybe flashing menu items) gets converted to animations. OK, admittedly, this is not necessary.
Secondly because I really would like to make NPC and hero position just an alias for the position of their slices so that you can actually use putslice on them, and the next logical step to to turn xgo/ygo into aliases for the motion properties of those slices too. Although maybe replacing xgo/ygo like that is just too difficult*.
This isn't a compatibility problem, but what about implementing new features, like textboxes sliding onto the screen, using slice motion? When everything is a slice, suspending slices would break stuff.
*There are two different types of slice movement, which don't map exactly to walkabout xgo/ygo, but that's only significant for the current buggy every-20-pixels collision checking. Otherwise, only the pixels to move on the current tick matters.
Secondly because I really would like to make NPC and hero position just an alias for the position of their slices so that you can actually use putslice on them, and the next logical step to to turn xgo/ygo into aliases for the motion properties of those slices too. Although maybe replacing xgo/ygo like that is just too difficult*.
This isn't a compatibility problem, but what about implementing new features, like textboxes sliding onto the screen, using slice motion? When everything is a slice, suspending slices would break stuff.
*There are two different types of slice movement, which don't map exactly to walkabout xgo/ygo, but that's only significant for the current buggy every-20-pixels collision checking. Otherwise, only the pixels to move on the current tick matters.
-
Bob the Hamster
- Lord of the Slimes
- Posts: 7660
- Joined: Tue Oct 16, 2007 2:34 pm
- Location: Hamster Republic (Ontario Enclave)
- Contact:
Oh, yeah, that makes sense.
Globally pausing all slice movement would prevent us for using slice movement for converting existing built-in movement features to become slice-based
I wonder if it would be worthwhile to add a bit to slices to indicate how they were created
It could be something like "user" and it would be true if the user created the slice with a command or by loading a regular slice tree.
It would be false if the slice was engine-generated, or loaded from an engine-internal saved slice collection.
That way we could make commands that only apply to one group of slices and not the other. It doesn't solve ever possible use case for wanting to selectively pause slices, but I think it would simplify many use cases.
We would have to think about issues like, if a slice is engine-created do we check its children for user-created slices, or vice-versa?
Globally pausing all slice movement would prevent us for using slice movement for converting existing built-in movement features to become slice-based
I wonder if it would be worthwhile to add a bit to slices to indicate how they were created
It could be something like "user" and it would be true if the user created the slice with a command or by loading a regular slice tree.
It would be false if the slice was engine-generated, or loaded from an engine-internal saved slice collection.
That way we could make commands that only apply to one group of slices and not the other. It doesn't solve ever possible use case for wanting to selectively pause slices, but I think it would simplify many use cases.
We would have to think about issues like, if a slice is engine-created do we check its children for user-created slices, or vice-versa?
[s](disclaimer: haven't read this whole thread yet)[/s]
Are your slices moving by command from your main loop, or are they using slice velocity or something else? In the game I'm working on, to allow gameplay and scripts in menus, I just made a global called "global wait" and set it to true whenever a menu opens. Then in the main loop I just put an if for all the stuff that should pause if "global wait" is true.
EDIT: Never mind, sorry, this is not helpful.
Are your slices moving by command from your main loop, or are they using slice velocity or something else? In the game I'm working on, to allow gameplay and scripts in menus, I just made a global called "global wait" and set it to true whenever a menu opens. Then in the main loop I just put an if for all the stuff that should pause if "global wait" is true.
EDIT: Never mind, sorry, this is not helpful.
Last edited by kylekrack on Mon Apr 03, 2017 10:07 pm, edited 2 times in total.
My pronouns are they/them
Ps. I love my wife
Ps. I love my wife
The engine-created bit would be quite similar to the Protect bit (which is applied to nearly all engine-created slices). I was implementing a per slice command which disallows pausing protected slices such as the walkabout layer (with a special case for the script layer), to make sure walkabouts can't be affected.
(The only things that could get converted to slices movements or animations are sprite dissolve animations, walkabouts, built in menus (eg Quit), tile/tilemap animations, and maybe flashing text in menus and choiceboxes.)
I'm not sure about lumping together movement and animation. Although in most cases you would want to pause both, there might be exceptions so maybe we should just have two bits, and separate sets of commands. Better plan these out now to allow consistent naming.
The Paused (previously, Mobile) slice attribute currently pauses all children too. This would be really convenient for pausing everything parented to a layer, but we could instead make the bit not apply to children, and instead make the script commands (optionally) apply the bit recursively.
That way we can allow recursive pausing the Walkabout Layer without affecting NPCs. However, then we would have the opposite problem: not having a way to pause engine slices in the future, if you do want to do so, and I don't like having those unnecessary limitations. On the other hand the Protect bit restriction I mentioned is only temporary until we've finished converting existing stuff. Currently we have a compatibility reason to disallow it, but that will disappear in future.
Also, we already have "stop slice" and "wait for slice" commands, and "stop slice" applies only to a single slice, not recursively. On the other hand "set slice visible" is recursive.
I thought that having "wait for slice" wait for animations too would be most intuitive; but the alternative is to add separate "wait for animation(sl)", "stop animation(sl)", "pause animation(sl)", etc commands.
(The only things that could get converted to slices movements or animations are sprite dissolve animations, walkabouts, built in menus (eg Quit), tile/tilemap animations, and maybe flashing text in menus and choiceboxes.)
I'm not sure about lumping together movement and animation. Although in most cases you would want to pause both, there might be exceptions so maybe we should just have two bits, and separate sets of commands. Better plan these out now to allow consistent naming.
The Paused (previously, Mobile) slice attribute currently pauses all children too. This would be really convenient for pausing everything parented to a layer, but we could instead make the bit not apply to children, and instead make the script commands (optionally) apply the bit recursively.
That way we can allow recursive pausing the Walkabout Layer without affecting NPCs. However, then we would have the opposite problem: not having a way to pause engine slices in the future, if you do want to do so, and I don't like having those unnecessary limitations. On the other hand the Protect bit restriction I mentioned is only temporary until we've finished converting existing stuff. Currently we have a compatibility reason to disallow it, but that will disappear in future.
Also, we already have "stop slice" and "wait for slice" commands, and "stop slice" applies only to a single slice, not recursively. On the other hand "set slice visible" is recursive.
I thought that having "wait for slice" wait for animations too would be most intuitive; but the alternative is to add separate "wait for animation(sl)", "stop animation(sl)", "pause animation(sl)", etc commands.
Last edited by TMC on Tue Apr 04, 2017 2:16 am, edited 4 times in total.