Fix midpoint expression to use converted expressions#8644
Open
Dev-Xeiji wants to merge 1 commit into
Open
Conversation
🔍 Triage ChecklistType
Project
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The midpoint expression only worked properly when both inputs were already locations or vectors.
#8625
Solution
The expression now checks the possible return types using existing converters, then converts both inputs to the correct type during initialization. This allows values like blocks to be treated as locations when a valid converter exists.
PS: The actual midpoint calculation was left unchanged.
Testing Completed
Tested manually with two defined variables and confirmed that the midpoint expression now works when the blocks are converted to locations.
Supporting Information
Completes: #8625
Related: none
AI assistance: none