-
Notifications
You must be signed in to change notification settings - Fork 30
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
v0.9.2 kOS doesn't detect the reference transform has changed when the ship splits. #281
Comments
Would that suggested fix have a problem if the user has manually selected a "control from here" that isn't the same orientation as the first KOS module, and then activates a stage? The first kos module, by the API's reckoning, might be a rover with a deliberately sideways KOS module on it that wasn't meant to be the module used for flying - it was meant to be used for driving later, so switching to its orientation in midflight when you drop a lifting stage (and therefore you have changed the partcount) could be disastrous. Presumably the Mod "knows" which KOS CPU is the one on which a program is running. So instead of orienting by the "first" kOS module, how about if the Mod chooses its orienting by "whichever module is the one that's running this "lock steering" handling routine that I'm working on right now." |
It would be predictable in that scenario, when you spawn the vessel, that node fixes the orientation to itself, and every time you stage it refixes. It wouldn't be as predictable when docking - which module becomes first depends on which the player is "in". However, you are absolutley right, it's not a good fix. I think the correct ifx is to interrogate the vessel on every boot and part count change, and then transform every thing so that "steering" is always relative to the kOS unit as you suggest - but provide a SHIP:CONTROL rotation (and possibly a SHIP:CONTOL:LOCATION vector) - however this is a somewhat more complicated solution. |
Hmm. KOS runs separate code simultaneously on separate modules. I wonder what would happen now without any code changes if you tried to "lock steering to up." on one KOS module, but then tried to "lock steering to north" on another module, and these two different modules are both attached to the same ship at the same time. Which one "wins" that fight? |
they both apply torque based on where they are and want to be - but I unlock steering after docking. |
"normally" it doesn't matter - it's the other half of the ship that changes, and even then the direction was about the same. However when they don't match up the craft spins ...er... chaotically, as the torques kOS calculates are applied at odd angles.
Once the user manually does a "control from here" action the system handles things in its usual way.
Suggested fix - the first kOS module in a vessel always makes itself the current transform whenever it boots or the partcount changes.
possibly?
The text was updated successfully, but these errors were encountered: