-
-
Notifications
You must be signed in to change notification settings - Fork 371
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
Introduces toggle effect & expression #4154
base: dev/feature
Are you sure you want to change the base?
Conversation
I have the same question I had with Delta’s PR initially: why would you add a new ChangeMode value? Toggling a boolean is essentially equal to setting the boolean to its opposite value. If anyone can give me one type that could use toggling except booleans, then go ahead, but in my opinion this should just be added as a separate effect and use the set-operation to perform the action. |
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.
Expression's javadocs for change and acceptChange should be updated
src/main/java/ch/njol/skript/expressions/ExprEventCancelled.java
Outdated
Show resolved
Hide resolved
Co-authored-by: TPGamesNL <[email protected]>
…feature/toggleChanger
It's more intuitive and makes more sense than toggle the value manually. For example: set flight mode to false # Bruh
toggle flight mode # This is good
Yes it is, but what's the most intuitive for users? Having a boolean "state" expression, or use a simple toggle?
I did that in a first time, but try to reuse an effect in addons, this is just impossible or really tricky/hard to do. What we would like is a simple api for addons developers that anyone could use it easily. Adding a mode makes things easier than adding an effect, and trying to use this effect. |
You're understanding me wrong. What I'm saying is that the internal structure of this feature does not make sense to me.
|
Yeah, but here is the problem: how do you manage that with addons? |
Addons that register boolean expressions can just accept SET as a valid change mode? |
Hey, I don't really get what you mean, why shouldn't TOGGLE be a mode? |
Not really. I am advocating for the removal of this ChangeMode because toggling equals setting a value to its opposite. This means that all boolean expressions that accept 'set' as a valid ChangeMode, can be toggled, since, again, toggling equals setting a value to its opposite. |
I think both ways are useful as a GhangeMode and as an expression.
I don't think this is correct, it is technically setting to it's opposite but to do this manually you will need a work-around and it will be longer that just |
You are not understanding me correctly but at this point I think it doesn’t matter anymore. |
I would like to understand your opinion of course, let me know more. It does matter :) |
My point is that you can toggle using current SET mode like this set flight state of player to false if flight state of player is true else true
# OR
if flight state of player is true:
set flight state of player to false
else:
set flight state of player to true Which works perfectly but adding toggle flight state of player
send "Flight state has been set to %toggle flight state of player%"
# OR
set flight state toggled {Flight::%uuid of player%} Makes it easier in some cases if not many, Am I correct? |
@Mwexim's point is that |
But with that it won't be possible to do |
Yes that would be possible, TOGGLE is not a ChangeMode in that code: https://pastebin.com/mEvXw429 |
If that works well I think it is a better idea, because it will be easier and no need to add TOGGLE ChangeMode to all boolean type expressions manually. |
Oh okay, that's what I didn't understand, how we could do that without a mode. It seems to be a good way to do it. I'm gonna probably change for that (and adding a new expression if the community wants to) |
This pull request is not ready to be review due to some changes to do. I convert it to draft during this time. |
Just because we made a mistake before doesn't mean we should do it again. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
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.
Good
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.
mainly formatting/style recommendations.
List<Object> filteredValues = toggledValues.stream().filter( | ||
obj -> ChangerUtils.acceptsChange(toggledExpr, ChangeMode.SET, obj.getClass()) | ||
).collect(Collectors.toList()); | ||
toggledExpr.change(event, filteredValues.toArray(), ChangeMode.SET); |
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.
We might need to note a behavior change here. For changing something like a list, I believe the indexes will now be lost, which was not prior behaviors. We might choose to only rewrite the list if it contains a boolean?
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.
When you're talking about the list, are you talking about the toggledExpr
or the filteredValues
, or even both?
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.
if we have a list like {_values::*}
with:
{_values::pickle::name} = "APickledWalrus"
{_values::pickle::likesCake} = true
if we then do toggle {_values::*}
, the indices such as name
and likesCake
will be lost (replaced by 1
and 2
).
This is probably unavoidable. However, if we have a list like
{_values::pickle::name} = "APickledWalrus"
{_values::pickle::githubName} = "APickledWalrus"
if we then do toggle {_values::*}
, there are no booleans to toggle, meaning we should not update the list (and cause it to lose its indices)
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.
Looking at the code, don't i already do it?
Also, tests are failing, did i misunderstand what you meant?
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.
There may have been some confusion, sorry.
Given a list containing "one" and "two"
, doing toggle {_list::*}
should not modify the list since there is nothing to toggle (meaning the indexes will be preserved).
However, given a list containing "one", "two" and true
, doing toggle {_list::*}
should modify the list since the third value is a boolean (meaning the indexes will be lost).
I think the fix you made is correct, but the test is wrong.
Working with the testing you added, you should be testing:
set {_list::myFirstIndex::myFirstValue} to "hello"
set {_list::mySecondIndex::mySecondValue} to "world"
toggle {_list::*}
assert {_list::myFirstIndex::myFirstValue} is "hello" with "{_list::myFirstIndex::myFirstValue} should be toggled to 'hello'"
assert {_list::mySecondIndex::mySecondValue} is "world" with "{_list::mySecondIndex::mySecondValue} should be toggled to 'world'"
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.
Update: shouldn't we throw an error instead? If the user tries to toggle strings, it shouldn't work. If the variable list includes string, but also boolean, shouldn't we throw an error? Note that i don't think we should throw an error if all values are togglables.
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.
Well, we can't really do runtime errors. I don't think it is just an issue to ignore the values and only change the ones that are actually togglable. You could also opt to not make any changes if there is an invalid type.
The main point still stands, though. If the list contains only blocks, we do not want to actually call the change method as it will reset the indices.
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.
Can you confirm me the commit 8bc1de4 fixes this unexpected behavior?
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.
it looks reasonable
you may want to check out #7120 changeInPlace utility method
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 would need a usage example please. That being said, i will wait for this PR to be merged before doing any change regarding this change.
In terms of organization, either the changeInPlace
PR is merged before this one, and so i will apply the change here, or this PR is merged before, and so i will apply the change in the other PR.
In any case, we need to merge one of them to move on the other.
Co-authored-by: Patrick Miller <[email protected]>
Co-authored-by: Patrick Miller <[email protected]>
Co-authored-by: Patrick Miller <[email protected]>
Co-authored-by: Patrick Miller <[email protected]>
Co-authored-by: Patrick Miller <[email protected]>
Description
This pull request introduces the toggle effect and expression.
Target Minecraft Versions: /
Requirements: /
Related Issues: /