Skip to content
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

Open
JoCRaM opened this issue Dec 1, 2013 · 4 comments

Comments

@JoCRaM
Copy link

JoCRaM commented Dec 1, 2013

"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.

vessel.SetReferenceTransform(part);

possibly?

@Dunbaratu
Copy link
Contributor

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."

@JoCRaM
Copy link
Author

JoCRaM commented Dec 3, 2013

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.

@Dunbaratu
Copy link
Contributor

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?

@JoCRaM
Copy link
Author

JoCRaM commented Dec 3, 2013

they both apply torque based on where they are and want to be - but I unlock steering after docking.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants