-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement a proper solution to stop the music when a jukebox is destroyed #5800
base: minor-next
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that something like this is needed, but I'm not super happy with the "destroy" terminology. It feels too ambiguous.
This is already being called in `Block::onDestroy()`
/** | ||
* Called when this block is destroyed either when a player breaks it or is hit by an explosion. | ||
*/ | ||
public function onDestroy() : void{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like @dktapps I don't think that destroy
terminology is appropriate in this case. Perhaps, as with the placement logic, an onPostBreak
would be preferable? It would be less ambiguous and not so funny in the sense that the block would already have been destroyed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's desirable. If the block was already destroyed, contents of stuff like tiles wouldn't be accessible.
Personally I would lean towards an onExplode()
method or something similar. We already have the likes of onIncinerate()
for fire. The problem is that this would require multiple handlers to be implemented for dealing with tile drops.
if($tile !== null){ | ||
$tile->onBlockDestroyed(); | ||
} | ||
$target->onDestroy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this function only be called if the onBreak returns true? There is a return value, but it's never used, and yet it would make sense in this case. If the broken action has been confirmed, then we can call this function, which is there to perform post-broken actions.
Has anyone considered using I haven't thought much about the pros and cons of this approach, but I think it should be considered. |
Linking #4652 as I think these are two different solutions for essentially the same problem |
This PR has been marked as "Waiting on Author", but we haven't seen any activity in 7 days. If there is no further activity, it will be closed in 28 days. Note for maintainers: Adding an assignee to the PR will prevent it from being marked as stale. |
Introduction
The current solution presents some problems as first of all Tiles should not handle the behavior of blocks, instead of using the jukebox API to eject the disc directly boradcasts
RecordStopSound
, which causes the loss of the disc by destroying the jukebox which at the same time does not match the Vanilla behavior.This PR addresses the problems mentioned above by adding the
Block::onDestroy()
method, making the block not dependent on the Tile to manage this logic, which as a plus eliminates duplicate code inBlock::onBreak()
andExplosion::explodeB()
.