Can I reset the "clock" on a craft?

[jfull]

So, every craft has a clock that counts the amount of time that has elapsed since launch, or since it was separated from another craft. But is there a way to set that clock back to zero?

If this isn't possible to do, I think it would be a useful feature for the Devs or a Modder to add.

Lets say I launched a craft into Kerbin orbit way before the transfer window I intended to use to send it to another planet. It would be nice to reset the time on the craft so that it only counts the time since the mission actually began, instead of the time it spend waiting.

Or, if I had a craft that I brought back home from a mission and refueled in orbit and wanted to use for another mission (and another after that, and so on), I would want to reset the clock at the start of each mission so I know how long its been away from home, not how old the craft is.

Edited May 7, 2014 by jfull

[Red Iron Crown]

Quicksave with F5, then load with F9. Resets the MET timer.

Edit: Or not, see below.

Edited May 7, 2014 by Red Iron Crown

[Boomerang]

If you're down with editing the persistence file, the 'lct' property near the top of the vessel info is the number of seconds elapsed since the start of the mission. So you could replace what ever is there with a '0' and the counter would reset next time you load the game.

Dunno if there's a mod that has any such functionality.

[Kasuha]

Quicksave with F5, then load with F9. Resets the MET timer.

Nope, doesn't work for me.

If you break your ship (e.g. separate a stage or undock a probe), the separate part gets its own new MET timer which start at the moment of separation. Maybe if you switch control to a probe core, then decouple it (axial, not radial decoupler), you may reset the MET timer on your ship. Gotta try it...

Edit: nope, MET timer stays with root part, the detached child part gets its MET timer cleared. This might mean it might be possible to clear the MET timer by docking...

Edited May 7, 2014 by Kasuha

[jfull]

Nope, doesn't work for me.

Yeah, I've flown tons of long-duration missions and needed to load quicksaves durring the course of them, and I can't recall any time that it reset the timer.

[jfull]

If you're down with editing the persistence file, the 'lct' property near the top of the vessel info is the number of seconds elapsed since the start of the mission. So you could replace what ever is there with a '0' and the counter would reset next time you load the game.

Dunno if there's a mod that has any such functionality.

I may or may not try that, I'm not sure I'm comfortable with getting into the persistence file, but that edit doesn't seem like it could mess anything up.

[Red Iron Crown]

Strange, it happened to me last time I quickloaded (after Jeb fell off the ladder on an Eve lander). I wonder what caused it.

[Kasuha]

Confirmed: docking to a station and undocking from it resets MET of a ship. It does not reset the MET of the station ... and I am not sure how the game decides what is the "station" and what is the "ship".

[Kasuha]

Strange, it happened to me last time I quickloaded (after Jeb fell off the ladder on an Eve lander). I wonder what caused it.

Are you sure it is not MET of that Kerbal? When you send a Kerbal on EVA, he gets his MET cleared.

[Red Iron Crown]

Are you sure it is not MET of that Kerbal? When you send a Kerbal on EVA, he gets his MET cleared.

Herp derp, you're right.

[jfull]

I'm gonna go ahead and call this one answered.

Thank you everyone who did offer some suggestions

[KerbMav]

I am not sure how the game decides what is the "station" and what is the "ship".

It does not - you did, didnt you? (Marking the craft as station by renaming it?)

[Kasuha]

It does not - you did, didnt you? (Marking the craft as station by renaming it?)

No, I was not renaming anything. And the question is rather what will be the root part and what will be the "appendix" after two ships dock. Because that's what affects the MET.

[Padishar]

No, I was not renaming anything. And the question is rather what will be the root part and what will be the "appendix" after two ships dock. Because that's what affects the MET.

This is a subject that would benefit from an in-depth analysis along the lines of your fuel flow thread (though there probably aren't as many cases to consider). I believe (mainly from the evidence of the MET, I haven't done any explicit tests) that when you dock one craft to another it re-roots the craft you are flying to have the docking port as the root before attaching it to the destination port. I don't know what it does when you undock again, it may leave it with the docking port as the root or it may remember what the previous root was and reset it when you undock.

It would also require some sort of plugin to display (or at least log) info about the crafts so you can see what the root is at any particular point. The latest version of KER has some useful code for dumping out the whole of the part tree. I'll have a look at adding a button to the engineer tweakable window that simply dumps the part tree to output_log.txt and then run a few tests...

Edited May 8, 2014 by Padishar

[Kasuha]

This is a subject that would benefit from an in-depth analysis along the lines of your fuel flow thread (though there probably aren't as many cases to consider). I believe (mainly from the evidence of the MET, I haven't done any explicit tests) that when you dock one craft to another it re-roots the craft you are flying to have the docking port as the root before attaching it to the destination port. I don't know what it does when you undock again, it may leave it with the docking port as the root or it may remember what the previous root was and reset it when you undock.

It would also require some sort of plugin to display (or at least log) info about the crafts so you can see what the root is at any particular point. The latest version of KER has some useful code for dumping out the whole of the part tree. I'll have a look at adding a button to the engineer tweakable window that simply dumps the part tree to output_log.txt and then run a few tests...

According to this experiment, root is switched back (or at least away from the docking port) after undocking. Similar technique could be potentially used to figure out what's happening with docking/undocking in general.

[KerbMav]

No, I was not renaming anything. And the question is rather what will be the root part and what will be the "appendix" after two ships dock. Because that's what affects the MET.

I meant, the game knows a craft is a station because it is marked as a station.

[DoToH]

I meant, the game knows a craft is a station because it is marked as a station.

But has this some influence on which one of the two root parts before docking will be the root part of the ship after docking? (I'm assuming one of them has to be the new root part.. if I'm wrong, please correct me)

[Claw]

According to this experiment, root is switched back (or at least away from the docking port) after undocking. Similar technique could be potentially used to figure out what's happening with docking/undocking in general.

Yes, it appears the parent docking port remembers the UID of the child's root, the child's craft type, and the name of the child craft. The child craft gets shuffled a bit with the child's docking port becoming the child's connection point, and the child's docking port takes on the mothership's docking port as its parent. When the ship splits, the child is reshuffled back and the root part becomes the root again.

At least this is what I can discern fom studying save files.

I suspect some of the undocking woes are within this splitting/reshuffling process. I've been able to find a way to split ships by using a different connection method within the save file. It's not convenient, but it seems to be effective in splitting stuck docking ports.

[DoToH]

Yes, it appears the parent docking port remembers the UID of the child's root, the child's craft type, and the name of the child craft. The child craft gets shuffled a bit with the child's docking port becoming the child's connection point, and the child's docking port takes on the mothership's docking port as its parent. When the ship splits, the child is reshuffled back and the root part becomes the root again.

So the fact that one of the ships is tagged as "space station" doesn't matter when choosing the parent ship when docking. The ship you are controlling is allways the child. Correct?

[Claw]

So the fact that one of the ships is tagged as "space station" doesn't matter when choosing the parent ship when docking. The ship you are controlling is allways the child. Correct?

Oh sorry, that's not quite right. My post was mostly in reference to the structure of the craft in the save files and how everything gets shuffled around.

The choice of what becomes parent/child is a matter of (at least) two layers of priority, maybe three. I'm not certain of all these rules or where the thresholds are, but this is what some of my testing has shown.

Parent ship is chosen by:

1) Priority order from lowest to highest by craft type: Debris, Probe, Rover, Lander, Ship, Station, Base. The craft with the highest priority becomes the parent. Easy way to remember: this priority corresponds to the map filter order (buttons at the top).

2) If the two craft have the same priority, the "larger" one becomes the parent. (I don't know yet how larger is chosen, but I think it might be by part count.)

3) If the two craft have the same priority and size, the first one launched becomes the parent.

Like I said, I'm not certain these are all the priority rules, but it's what I've learned so far.

Examples...

- So if you dock a ship to a station, the station is the parent. When the Ship undocks, its timer is reset. (Here, I mean the "Ship" type, not just a generic craft.)

- If you dock a probe to a lander, the lander is the parent.

- If you dock a station to a base, the base is the parent.

[Padishar]

In all your examples, the thing you are docking to becomes the parent of the craft you are controlling. I'm not convinced there are any rules like you describe. It would be much simpler to implement if the craft you are controlling is always re-rooted and attached to the other craft as a child of the docking port. HarvesteR describes this here.

[Claw]

In all your examples, the thing you are docking to becomes the parent of the craft you are controlling. I'm not convinced there are any rules like you describe. It would be much simpler to implement if the craft you are controlling is always re-rooted and attached to the other craft as a child of the docking port. HarvesteR describes this here.

It is definitely NOT that whatever craft you are controlling becomes re-rooted and turned into the child. That I can say for certain. Quite frankly, the code is the same for whichever craft you are reshuffling so it wouldn't be "easier" or "harder" for to reshuffle one craft or the other.

As for my examples. Well, you got me by the virtue that I didn't think about how I was typing it, because I thought it was straight forward enough. I didn't say which craft was "in control" and which was the "target" but I can see it being read that way. I can just as easily say...

Examples...

- So if you dock a station to a ship, the station is the parent. When the Ship undocks, its timer is reset. (Here, I mean the "Ship" type, not just a generic craft.)

- If you dock a lander to a probe, the lander is the parent.

- If you dock a base to a station, the base is the parent.

I would say I typically think about it the other way, because that's the priority and that's what makes sense in my head.

Snippet of HarvestR's post...

Hierarchy shifts happen all the time as you play. Docking is what got that whole thing started, as as you docked, the 'docker' side of the pair would shift its internal part hierarchy so that the docking port itself was the root of the vessel, and everything from there down became children of it. Then upon undocking (assuming the vessel still contained its original root part... man, 0.18 was a pain to debug), we flip the hierarchy back again so the old root is now the parent for everybody else.

Now, with the whole 'we can now shift hierarchies' thing added, we saw that there was no need to enforce that a pod be the initial part on a ship. As long as it was something you could attach other parts to, there was no reason why anything couldn't be the root, but it did create the new problem in which the command pods now were not only optional, they also were possibly placed after decouplers. Hence, root-dropping.

Anyhow, I should get back to work here. Best of luck with your mod.

Cheers

I am certainly not trying to go against anything HarvestR is saying. I don't really know what you want me to say about it. I'm just trying to tell you that I can come across more than one situation where the vessel I'm controlling does NOT become the child.

If you don't believe me, go dock two craft together. Quicksave before you do and be in control of one of them. Dock and check. Then quickload, switch to the other, dock and check again. The parent will be the same.

You can also dock a vessel marked as a ship (in control) to a vessel marked as a lander (the target) and see which becomes the parent ship. By what you said, it's the lander. By the priority I listed, it's the ship.

Also, bear in mind that I did this testing with ships of similar composition. So if you find something different, like I said there may be other rules.

[Claw]

Funnyenough, I was specifically trying to avoid hijacking the tread. But since it's already answered... (Perhaps we should move this elsewhere?)

Here's a simple example. I made three craft, all identical. Two are marked as landers, named "Lander 1" and "Lander 2". The third craft is tagged as a Ship, and is named "Ship".

Examination of the save file craft order shows: Lander 2, Ship, Lander 1

First test, docking Lander 2 (in control) with Lander 1 (the target). By "simple" rules, Lander 2 should become the child and Lander 1, the parent.

Except what happened here? Lander 2 became the parent even though it was "in control" at the time of docking. That's because the craft are the same size and same type, so the one that's first in the save file wins. Examine the save file, Lander 2 is listed as one large VESSEL with a DOCKED_VESSEL of "Lander 1", and Ship is listed after.

Second Test:

Docking the Ship to the Lander 2 (now composed of "Lander 1" + "Lander 2"). By the simple rules, the Ship is "in control" and should become the child.

Again, that didn't happen. Ship became the parent even though Lander 2 is larger and listed first in the save file. That's because it's Type has priority.

Even if all my rules are completely wrong, I can say that it is definitely NOT the case that which ever craft is in control becomes the child.

Also, if people are going to keep digging, I should crush one other thing that may be mistaken from these two examples. They both show that the "in control" vessel becomes the parent. Realize that's because I was specifically trying to show that the "in control" craft does not always become the child. It doesn't matter which vessel you are "in control" of for either of these two examples. In fact, you can be in control of "Ship" when Lander 1 & Lander 2 complete the docking and Lander 2 always becomes the parent.

[Padishar]

Sorry, I missed this earlier. Yes, we should probably have taken this elsewhere.

Thanks for the new examples. I wasn't trying to say that you were wrong, I should probably have written "I'm not convinced by the evidence you have given that there are any rules like you describe." Thinking back over my time playing I think I have actually experienced the craft I was in control of staying as the root when docking when I was messing with a skycrane to rescue a stranded rover.

I have a very useful feature in my dev version of KER that adds a button to the engineer tweakable that dumps the part tree of the vessel into output_log.txt so I'm going to run a whole suite of tests on this because I will need to know the actual rules used for a mission planner plugin I am currently designing. It may take a while to devise and run enough tests to make firm conclusions but I will post a thread somewhere once I have some...

Edit: Out of interest, what is the root part of that craft?

Edited May 10, 2014 by Padishar

[Claw]

Sorry, I missed this earlier. Yes, we should probably have taken this elsewhere.

Thanks for the new examples. I wasn't trying to say that you were wrong, I should probably have written "I'm not convinced by the evidence you have given that there are any rules like you describe." Thinking back over my time playing I think I have actually experienced the craft I was in control of staying as the root when docking when I was messing with a skycrane to rescue a stranded rover.

I have a very useful feature in my dev version of KER that adds a button to the engineer tweakable that dumps the part tree of the vessel into output_log.txt so I'm going to run a whole suite of tests on this because I will need to know the actual rules used for a mission planner plugin I am currently designing. It may take a while to devise and run enough tests to make firm conclusions but I will post a thread somewhere once I have some...

Edit: Out of interest, what is the root part of that craft?

No sweat. I really was just trying to not completely hijack the thread with examples while explaining what someone asked.

I've moved this information to a new thread: http://forum.kerbalspaceprogram.com/threads/79594-Docking-and-Vessel-Type-Rules-%280-23-5%29

The root part in the pictures above are the probe cores closest to the modular girders that connect the wheels to the fuel tank. The root of the whole ship in that last picture is the probe core that I right-clicked on.