[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

So it seems parameters aren't quite as "local" as they're supposed to be, if they're able to mask off globally locked variables like that. darn it.

[Warringer]

I just came over a strange bug that sneaked up on me, while trying to optimize my RSS/FAR launch script.

More or less suddenly either of the computer cores heats up without cause (Deadly Reenty), making the launch vehicle explode in mid flight. If I remove Deadly Reentry, FAR causes the structural links to break up and the rocket explodes. And even before that, the control core connected to the computer core just detaches and needs to be held in place by struts...

I have no freaking idea what is going on...

[Tygroux]

I just came over a strange bug that sneaked up on me, while trying to optimize my RSS/FAR launch script.

More or less suddenly either of the computer cores heats up without cause (Deadly Reenty), making the launch vehicle explode in mid flight. If I remove Deadly Reentry, FAR causes the structural links to break up and the rocket explodes. And even before that, the control core connected to the computer core just detaches and needs to be held in place by struts...

I have no freaking idea what is going on...

Same thing here.

The COM suddenly move (the camera center moves 1-2 rocket height below the engines) when my booster stage reach around half fuel, then the CX4181 module gets burned by the booster/re-entry/aerodynamics/G-forces depending on the config used.

I tested with it at the top and middle of the rocket, and the rest of the rocket seems fine. It's just the script module (and anything attached to it) that gets ripped off by apparently infinite forces.

It also seems to happen always at the same time: When my booster stage reach half fuel. Whatever thrust limiter ratio I used.

I'm going to test it with other rocket setup, and edit this post with any finding.

EDIT: Stayputnik core, KOS module, FL-800, engine. and stayputnik, KOS, Booster.

The brutal COM move seems to happens at 60% fuel remaining exactly (in the first stage to fire). After what the KOS module is ripped off by whatever gets it first...

Edited December 9, 2014 by Tygroux

[Dunbaratu]

Same thing here.

The COM suddenly move (the camera center moves 1-2 rocket height below the engines) when my booster stage reach around half fuel

Can people having this problem save the output_log file immediately after this happens (as in, kill KSP immediately as soon as you see the camera pan back behind the rocket - don't come out nicely via the menus, just kill the program quickly using whatever means your OS uses for doing that.)

I'd like to examine the log as it exists at that point. It makes no sense what's happening there.

(And to make it clear, I'm referring to the camera moving behind the vessel problem, not the exploding part problem. The two might be related because whatever is miscalculating the position of parts could be miscalculating the heat a part is undergoing.)

[Dani]

The "Volume out of range" exception is not really an exception, but rather a bad coding practice instead of properly handing a return and logging a message. :-/

Edit: I personally think it has to do with a variable inadvertently setting before the scene change is complete... But then the question is what triggers it to move...

Edited December 11, 2014 by Dani

[Dunbaratu]

The "Volume out of range" exception is not really an exception, but rather [...]

I looked back about 2 weeks worth of the thread and never saw the word "Volume" mentioned in any previous post.

Can you elaborate as to what you're talking about? Presumably you're seeing this message when you think you shouldn't?

[Trewor007]

This is more a question out of curiosity rather than a problem.

I've created a small drop-ship, with 6 drop-pods controlled by, a very primitive program. The strange thing is that the manned pods are executing the drop correctly, but if i drop a empty one it flies of course on booster ignition. This is not a problem since i will drop them all with kerbals inside, but I'm really curios why the drop pods are behaving in such a way.

on AG9 { stage.}.
wait until ship:mass < 2.0.
print "separated".
sas off.
rcs on.


until 0{
if k=0 {wait 30. set k to 1.}.
if k=1 {set ship:control:top to 1. wait 1. set ship:control:top to -1. wait 1. set ship:control:top to 0. wait 2. set k to 2.}.
if k=2 {lock steering to prograde. wait 5. sas on. LIST ENGINES IN myVariable. FOR eng IN myVariable {eng:ACTIVATE.}. wait 5. sas off. set k to 3.}.
when ship:altitude<50000 then {lock steering to retrograde.}.
when ship:altitude<10000 then {unlock all.}.
when alt:radar<100 and k=3 then {toggle gear. set k to 4.}.
wait 0.001.
}.

print "gotowy". set k to 0.

[madlemur]

Quick look gives me the generic advice of pulling the WHEN statements out of the UNTIL loop. Set up your WHEN events before you enter the loop.

[Dani]

I looked back about 2 weeks worth of the thread and never saw the word "Volume" mentioned in any previous post.

Can you elaborate as to what you're talking about? Presumably you're seeing this message when you think you shouldn't?

Yeah I probably thought that the exception was posted on here as well for the "camera move" bug. It is in reference to https://github.com/KSP-KOS/KOS/issues/428.

[Warringer]

Can people having this problem save the output_log file immediately after this happens (as in, kill KSP immediately as soon as you see the camera pan back behind the rocket - don't come out nicely via the menus, just kill the program quickly using whatever means your OS uses for doing that.)

I'd like to examine the log as it exists at that point. It makes no sense what's happening there.

(And to make it clear, I'm referring to the camera moving behind the vessel problem, not the exploding part problem. The two might be related because whatever is miscalculating the position of parts could be miscalculating the heat a part is undergoing.)

I've made you a log file. -> http://goo.gl/yF4pNb

And I discovered that it might have something to do with the 'Start in Archive' setting in the configuration.

[Trewor007]

can anyone check and conform something?

when build a small ship with a stock probe with a KOS module, and save it as a subassembly. an when i use that subbassembly is such a way that it detaches from the ship, and use a "lock steering to..." command. the detached ship starts to spin instead locking into the correct orientation.

EDIT: this happens mostly in the SPH

Edited December 12, 2014 by Trewor007

[erendrake]

can anyone check and conform something?

when build a small ship with a stock probe with a KOS module, and save it as a subassembly. an when i use that subbassembly is such a way that it detaches from the ship, and use a "lock steering to..." command. the detached ship starts to spin instead locking into the correct orientation.

EDIT: this happens mostly in the SPH

Have you applied lock steering before or after you separate the subcraft? and to be clear do you mean this only happens when you save the subcraft as a "subassembly" in the SPH and then load it back and attach it to your craft?

I know that we have some issues around craft getting loaded/created/destroyed and having script execution continue.

[Trewor007]

after separation. for example the probe on the bottom is a root part created in the VAB, the probe on the top was created in SPH saved as the "bug test" subbasembly and attached to the root part in VAB.

this is how they react:

in this case the oscillation is light, when i tried this with a lander can they go like a tornado with spinning on all 3 axis.

EDIT: I was unable to reproduce the same effect on a fresh copy of KSP witch only KOS installed and added modules.

EDIT2: If a kerbal is in the capsule the spinning starts even with ships with no subassembly parts.

Edited December 12, 2014 by Trewor007

[Dunbaratu]

I can confirm that I had this problem when I was testing the docking use-case with some new Direction features I was implementing. In testing that case I often found that joining and separating craft triggered this. A workaround is to leave the scene and come back to it, forcing KSP to destroy and recreate the kOS parts into memory. In my case, subassemblies were not involved at all. It's the act of separating craft in flight that did it, and it was intermittent. Sometimes it happend and sometimes it didn't. I think it depends on which part of the vessel is considered the "root" part, which keeps changing when you dock and undock. (You've all seen the effect where you dock a vessel to a station and the game decides to rename the station to the name of your vessel you docked to it - when you see that it means the game decided your new vessel was to become the new root part of the joined together ship, rather than the station's previous core part.) I have no clue what criteria the game uses for this, but the point is that I think which part of the vessel contains the root part when you split the vessel apart affects which half of the vessel experiences the bug and which half doesn't.

Whenever you split a vessel into two halves, either through staging or undocking, it seems that it breaks off at the splitting point such that the next part further out from the split point becomes the root of a new parts tree for a new vessel, that follows the same branching structure from there. Meanwhile the original vessel is still there, but with one of its branches truncated at the split point.

The bug seems to only affect which of the two vessels is the newly invoked one. The vessel that consists of the original old one with a truncated branch still operates correctly. The vessel that was newly built starting with its new root at the branch point is the one that gets the bug. I strongly *suspected*, but haven't gone through the effort to actually prove, that the bug is because the new vessels' kOS CPU still has a variable in memory that tells it "I am part of vessel A", when it is actually part of vessel B now. This would lead to a whole host of confusion in the steering algorithm as it tries to read rotation, position, and velocity of the vessel and is getting back answers referring to the OTHER ship rather than its own ship.

The reason it is intermittent is that it's hard to predict which half of the split is going to become the "new" vessel, and it's almost as if KSP is picking that at random.

It just occurred to me how you could prove once and for all that this is the problem. When you experience this problem next, and one of the two parts is unable to lock steering properly, then do this while the problem is still in effect:

In terminal 1, PRINT SHIP:MASS.

In terminal 2, PRINT SHIP:MASS.

If they're on two different vessels that have different parts, they should return two different numbers.

If they both return the SAME number despite being on different vessels, that's proof that both CPU's still think they're part of the same ship as each other.

[Trewor007]

the terminal in the top right corner is from the root vessel, it shows corect mass of 24t.

the terminal on the bottom left is from the left lander can, unmanned, points correctly to prograde. corect mass of 1.2t.

the terminal on the bottom right is from the right lander can, manned, SPINS (it can be seen in the left corner). corect mass of 1.2t.

leaving the scene does not help, and in some cases is impossible (different bug)

as an observation:

the problem was effecting all the vessel both manned and unmanned, but now when I uninstalled TTNeverUnload mod the problem only with the manned craft separated from the root vessel.

[Dunbaratu]

the terminal in the top right corner is from the root vessel, it shows corect mass of 24t.

the terminal on the bottom left is from the left lander can, unmanned, points correctly to prograde. corect mass of 1.2t.

the terminal on the bottom right is from the right lander can, manned, SPINS (it can be seen in the left corner). corect mass of 1.2t.

http://s14.postimg.org/5mwm1grsh/Untitled.png

Unfortunately that's inconclusive, as I didn't realize you'd have multiple vessels with the exact same parts list on them. I was assuming each broken apart vessel would be unique enough not to be the same mass. Knowing that they both say 1.2t doesn't help if both really indeed *are* 1.2t in mass.

I was hoping for a situation in which it would be *incorrect* for them to give the same mass because they are different. In that situation, them giving the same mass would be proof of the bug. But in this case, them giving the same mass might be correct.

Try it with the SHIP:NAME field instead. Rename one of the two vessels, and then see if the two terminals give different names or the same name. If they give the same name despite the fact that the two vessels are named differently, then that would be proof of the bug.

[Trewor007]

ships see they have new names. the ones with the kerbals still spin

maybe there is some kind of log or output file a can give You for analysis?

[Dunbaratu]

ships see they have new names. the ones with the kerbals still spin

maybe there is some kind of log or output file a can give You for analysis?

Sadly I don't think what I'd need to know would be in it because it would only log things it *knows* are problems. And this is a case of it not realizing how wrong it is being.

For a full debug I'd have to change the mod's code to do a verbose dump of the *entire* context of each CPU's state of mind and what it's thinking as it steers, and work backward from the steering code to which piece of data is wrong and where it came from. The steering code is really more @erendrake's area so I'm not sure I should jump into it.

What might help is providing a savegame file of the exact moment of time just before the undocking happens. Although, that would also mean having to make sure the exact same list of other mods you have is installed on the test platform just to be sure we can load the savegame.

[Trewor007]

i think i found the problem.

but i hard to explain it because of the language barrier.

if the root part of the ship contains a place that can hold a kerbal(pod, cockpit or living quoter) the problem does not exist. the part does not have to be occupied by a kerbal it just needs to be there.

if the root part is, a probe and there is a kerbal in a pod on the part that is gone be detached that part will go nuts.

it all depends on witch side of a decoupler the kerbal is.

https://www.youtube.com/watch?v=U3SR__KZWt4

[Dunbaratu]

i think i found the problem.

but i hard to explain it because of the language barrier.

if the root part of the ship contains a place that can hold a kerbal(pod, cockpit or living quoter) the problem does not exist. the part does not have to be occupied by a kerbal it just needs to be there.

Are you using ModuleManager to add kOS to all the command cores? The problem might be related to having the computer pilot and the pilot made of meat in the same part.

[Trewor007]

only on the probes. having kos and kerbals on different parts is against my gameplay rules. ive only did that once when i was thinking the reason of spinning was having kos probe interfering with kerbal in the lander can.

[Dunbaratu]

only on the probes. having kos and kerbals on different parts is against my gameplay rules.

These two sentences contradict each other. I'm confused.

[Trewor007]

oh sorry i meant on the same part.

[John FX]

Hi, I used to use KOS back in the middle of the year (around v9 or so)

Would my old scripts still work or have the functions of old commands changed?

[Trewor007]

some things have changed.

https://github.com/KSP-KOS/KOS/blob/master/CHANGELOG.md

but its easy to make changes to the code and it will work again.