Standalone KOS interpreter #2
Open
Conversation
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
Fixes KSP-KOS#2861 by replacing ProcessOneInputChar()'s use of defaulted optional parameters with just having different explicit signatures instead. This way previously compiled DLLs will pick the right one, which they cannot do with defaulted args because in C# defaulted args are appended at compile-time, not run-time or load-time. If the signature required appending one extra optional arg back when the compiler ran to build the caller's DLL, but it now would need to append two such args, the DLL will still be trying to get away with just appending one. Thus why the kOSPropMonitor DLL still insists on a 3-arg method existing or it won't work. tl;dr - adding more parameters but making them defaulted only provides backward compatibility when all DLLs that call the method are getting recompiled from scratch. It doesn't when the caller is a DLL that's not being recompiled.
The problem of the latter buttons not taking focus from the text area stems from Unity IMGUI being weird about what things can and cannot take focus. Because it doesn't support keyboard control of buttons, you can't tab into buttons. So the idea of a button taking control away from a textarea doesn't work right at all. So I had to invent my own focus rules to make it properly take focus away from the text field when a button is clicked. I explicitly tell INGUI to switch which control has focus when the button click happens, since it won't always inherently do it. Secondarily, the multi-ONCONFIRM on earlier buttons is because the IMGUI system is sometimes calling OnGUI during "layout" passes in between the repainting passes. During those in-between calls, the call to GetControlID() returns -1 because it hasn't heard of the current widget yet during the layout pass. It doesn't have control ID's decided until subsequent OnGUI passes, after the layout pass is over. So the textarea incorrectly thought its control ID was -1 for just one OnGUI pass, making it think it just lost focus because the focus'ed control doesn't match the "current" ControlID of -1. Then on the next OnGUI pass it would get the proper ControlID info and realize it never really lost focus, except it *acts* as if it lost focus then regained it because of that one pass where it was -1. To get rid of that problem, I changed it so that when it sees a ControlID that is negative, it doesn't believe it's true. Instead it bypasses the focus check on any pass where the ControlID is negative, knowing it will eventually get a real, meaningful ControlID to work with on a future pass of OnGUI(), and only THEN should it try checking if the focus is in the current textarea widget or not.
Can work as a solution to KSP-KOS#2889, KSP-KOS#145
The fix I went with was to detect whether or not a raycast hit is inside a Part. If it is, then start a new raycast just past the hit and keep looking. The solution involved writing a wrapper around Raycast that includes this extra logic, such that it could be lifted and put in a utility library later if any other classes need to use it.
I thought I had solved this in the previous commit but noticed it failed in gameplay. My math wasn't quite right. The problem fixed in this commit only shows up when you aren't on the equator, which is why it wasn't seen in testing on the KSC runway. The issue is that I changed algorithms partway through implementing this but didn't fully edit the code to reflect the new algorithm. What I had was a mix of the two. Prev algorithm was "calculate new raycast start by adding (distance plus a bit)*aimvector to the previous start point". New algorithim was "Calculate new raycast start by just using the hit location directly, plus aimvector times a little". The old algorithm required a +=, and the new one just an =. I missed that edit, and that mistake caused it not to work when not on the equator (essentially, when the Z axis of world coords isn't zero, the bug manifested.)
Because of the haphazard indentation in the part cfg files, I placed the kOSMachine1Rad's cargo info outside the curly braces for the PART. While I was fixing that I also decided to go through and fix the indentation on all the part files to make them consistent with each other.
Fixes KSP-KOS#2912. The problem only exists in KSP 1.11 and up. In KSP 1.10.x and earlier, it was working. The problem was caused by the introduction of RCS part variants that came with KSP 1.11.x. Restock happened to exacerbate the problem because it has more part variants, but even the part variants that come with stock are enough to trigger the problem. The problem is that kOS's replacement for GetPotentialTorque() was adding up the superset of all the part variants' thruster nozzles, not just the nozzles that actually exist in the current part variant. You'd think that KSP would cull out the nozzles for other part variants when it builds the ModuleRCS.thrusterTransforms list, but it doesn't seem to do that, so we have to cull them ourselves when iterating over that list.
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.
Very rudimentary standalone KOS processor.