Skip to content
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

Add WILL to property condition #5955

Merged
merged 3 commits into from Oct 7, 2023

Conversation

TheLimeGlass
Copy link
Collaborator

@TheLimeGlass TheLimeGlass commented Aug 31, 2023

Description

Add WILL to property condition. This can be useful. For example player will consume the firework charge in a elytra boost event. The main context I can think of would be for event conditions.

  • Code cleaned the PropertyCondition class.
  • This will not conflict with CondCompare time states.
  • Time identifiers can still be sent through the register PropertyCondition. %players@1%

Target Minecraft Versions: none
Requirements: none
Related Issues: #5120, #5956 (use case)

@TheLimeGlass TheLimeGlass added the enhancement Feature request, an issue about something that could be improved, or a PR improving something. label Aug 31, 2023
@Fusezion
Copy link
Contributor

Would it be worth to reopen #5120 an issue originally opened by me to suggest adding this? Was closed only as it seemed like it didn't seem planned nor useful really.

@TheLimeGlass
Copy link
Collaborator Author

TheLimeGlass commented Aug 31, 2023

Would it be worth to reopen #5120 an issue originally opened by me to suggest adding this? Was closed only as it seemed like it didn't seem planned nor useful really.

Done. You self closed it, not someone on the team. The difference between CondCompare and this, is the fact that CondCompare requires to take in two expressions, so we don't have support currently.

You should in most cases use an Expression and time states, but when it comes to boolean states, like what I found with elytra boost consume rocket, you will need it as a condition. And with the future additions of pull request #5219 this will be more common.

@Moderocky Moderocky changed the base branch from master to dev/feature September 17, 2023 07:33
@Moderocky Moderocky added the feature-ready A PR/issue that has been approved, tested and can be merged/closed in the next feature version. label Sep 17, 2023
@TheLimeGlass TheLimeGlass merged commit 83a41f6 into dev/feature Oct 7, 2023
6 checks passed
@TheLimeGlass TheLimeGlass deleted the enhancement/will-property-condition branch October 7, 2023 05:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature request, an issue about something that could be improved, or a PR improving something. feature-ready A PR/issue that has been approved, tested and can be merged/closed in the next feature version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants