Conversation
| Object.DestroyImmediate(m_Settings); | ||
| m_Settings = state.settings; | ||
|
|
||
| settings = state.settings; |
There was a problem hiding this comment.
So the theory here is that using the property instead of a direct setter makes sure we update all the derived data (static caches) -- that happens in ApplySettings that is ignored in here.
There was a problem hiding this comment.
Ah, good catch, since the property setter triggers the apply settings.
Codecov ReportAll modified and coverable lines are covered by tests ✅ @@ Coverage Diff @@
## develop #2186 +/- ##
========================================
Coverage 65.43% 65.43%
========================================
Files 367 367
Lines 53505 53505
========================================
Hits 35013 35013
Misses 18492 18492
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
|
Just made this PR ready for review because the CI redness on iOS and tvOS looks caused by xcodebuild timing out while waiting for some update or whatever. Not related to this change. |
ekcoh
left a comment
There was a problem hiding this comment.
Approving this fix but it would be great if we could add the missing test coverage for this, which seems unrelated (as you say) to the specific setting but relates to the restoration of settings after e.g. a domain reload. I wonder if we could get it covered by exiting and then re-entering playmode from a test.....
| Object.DestroyImmediate(m_Settings); | ||
| m_Settings = state.settings; | ||
|
|
||
| settings = state.settings; |
There was a problem hiding this comment.
Ah, good catch, since the property setter triggers the apply settings.
| } | ||
|
|
||
| // Create temporary settings. In the tests, this is all we need. But outside of tests,d | ||
| // Create temporary settings. In the tests, this is all we need. But outside of tests, |
|
Did not forget this one, will try to review it today/tomorrow |
885241b to
4ddce95
Compare
|
In the end, I think I would send the UTR change with this PR because otherwise it's very painful to get a green automation run on this PR otherwise |
|
I didn't make a test here in the end, I think I just don't know how to make a meaningful one without making a new test project with the updated defaults |
… a bit of derived state that is invalid otherwise
…nd tvOS instabilities (per the Slack advice)
f0ab047 to
5735715
Compare
Description
This is an attempt to fix the problem where in Editor we would really apply the default input settings correctly. Like, we would read them, but we wouldn't correctly update the derived static properties so whenever that happens, we have issues like the default button press point being incorrect.
Looking at code, I believe it's not just the default button press point that was incorrect, I think all of these folks were incorrect too (though the bug report won't mention them):
Testing status & QA
Local testing, pending a QA pass.
Overall Product Risks
Comments to reviewers
Please describe any additional information such as what to focus on, or historical info for the reviewers.
Checklist
Before review:
Changed,Fixed,Addedsections.Area_CanDoX,Area_CanDoX_EvenIfYIsTheCase,Area_WhenIDoX_AndYHappens_ThisIsTheResult.During merge:
NEW: ___.FIX: ___.DOCS: ___.CHANGE: ___.RELEASE: 1.1.0-preview.3.After merge: