MarvinCZ

Thank you for the explanation, it makes more sense now. I'll try adding a sentence to the Concepts page on the project wiki, I hope that's OK. It should help people like me, trying to navigate L2 orbits and frustrated at the weird trajectories they get with the regular barycentric frame. Edit: I added this sentence to the Wiki: "This frame may also be useful for navigation around Lagrangian points L1 and L2 thanks to their proximity to the smaller celestial." And thanks for being able to even have a discussion about libration points in KSP

Hello, I have a suggestion for the Principia Wiki - Concepts page. I'd suggest the reference frame fixing the centre of a celestial, the plane of its orbit around its parent, and the line between them is ideal for maintaining orbit around an L2 point, or at least the Earth-Moon L2. It's certainly better than the Earth-Moon Barycentric reference frame, which is what the page suggests for Lagrangian points. I'm not sure about the other Lagrangian points, the barycentric reference frame may be the best there. For the Earth-Moon L2, though, the EMB reference frame makes it harder than MCEA because an orbit is harder to recognize. It's especially noticeable when attempting orbit insertion. For illustration, this shows how an orbit around the Earth-Moon L2 point is displayed in both reference frames. It's even more evident with longer orbits. In EMB, the orbit appears almost random. Earth-Moon Barycentric: Moon-Centred Earth-Aligned:

@Agustin Also a word of notice: If I remember right, if you apply the mod to a save game in progress, it should be with no vessels in space, otherwise they can end up in random locations.

I had a similar problem to yours but in my case the game told me to return the crew in my Space station and keep the capsule in space I think in my case it may have been caused by me changing the control point ("Control from here") when the two were joined. Unfortunately, I didn't figure out a way to fix it. I manually marked the contract as completed like you and it's been broken ever since.

How did you place the LR-101s? They should be on the side of your fuel tank to have as much roll input as possible. Like on the Atlas, where the engine comes from: http://files.abovetopsecret.com/files/img/yj4f06d4f1.jpg Also - sorry if this is obvious - this won't remove the natural tendency to roll. It will just give you a way to correct it in flight. You will need to either have SAS turned on or apply roll corrections manually. The Test flight data is for rp-0, it uses its own engine configs.

If I used a single F1 on my rocket, it also started to spin increasingly as it flew. Clustered setups eliminate that problem, either by balancing out the inconsistency or just correcting it with gimbal. If you want a single F1, a pair of LR-101s can keep the roll in check. The Test Flight data really isn't there. I would welcome it. Surely the F1 has a rated burn time? A reasonable failure rate can be probably guessed too.

So, I have an issue of my own. I built my first Space station, with a Station Science Module (early). I crewed the station (including a scientist) and tried performing experiments. I got a message "Cannot perform experiment when part is shielded". Is that a bug of the "Cannot deploy while stowed" sort? Can I do something to make the module work? I don't really care if it takes a man with a screwdriver fixing this station or launching a new station.

Many of the small cores - namely Agena and the probe cores - can have avionics shut down. That reduces power drain to very little. If you activate avionics only for maneuvers, they will probably last to the Moon on battery power alone. If you want to make sure, even basic solar panels should be able to recharge your power in that state.

Thank you. I'll see if I get anything worthwhile to report about it.

Hello! Sometimes when I transmit larger chunks of science (e.g EVA report from space using just the Mk 1 capsule antenna) when the transmission completes and shows "Done!", the science just gets lost, like nothing was transmitted. Is that a feature or a bug? I will provide a full report if it's a bug, I just want to make sure I'm not missing something.

It is a Module Manager patch. That means you need to save it as a .cfg file and put that in your GameData folder. You could perhaps put it in the BADTProps folder.

HE is this mod - Hangar Extender.

Oh, I'm sure there are more, I'm overdramatizing. That thing was my bane, so I shall paint it in an ominous light!

Hmm, you are a serious contender for my bet. That was some great flying and shooting. It might well be what is needed to destroy the ominous Tytonid.

For some reason I had the idea that there are two battles left, don't know why. I noticed that the second battle was just barely uploaded when I linked it.

Here we go!

I bet on ferram4's Tytonid. I felt what it can do. I will also get to say I was defeated by the best :-)

Wow, that was the fastest one yet, I think. I expected to lose this one, so no surprise there. That aim was crazy, though. Really a great plane, @ferram4. So, any chance of some pointers for improvement? I can design a plane that flies well in general but I don't know how to optimize for dogfighting. One thing I know from the discussion earlier in the thread - the AI response and damping are too high.

BDA uses heat as damage for game engine reasons, not because it simulates damage through thermal radiation. Most weapons BDA simulates are HE and would behave the way theonegalen described. That being said, it may be either a feature or just a "lucky" bug.

That is the battle I had hoped for - intense, with violent action and both parties putting up a good fight. I'm a bit glad that the winner didn't change, which could be cruel to Veeltch. Noir's plane deserved to show us what it got, though. Edit: About competition mode for all battles - I don't think it's necessary if both planes manage to get ready and meet in fair combat.

I would personally feel better about it, even if the resulting winner was the same. That battle was quite affected by this. The first plane always went down before it was ready to fight and the second of the pair ended up with two enemies on its tail. Note that none of the planes in the fight were mine, and I am sorry for causing you extra work with these complaints.

In addition to the fixes posted above, you can also start only the pilots at first, and enable Guard mode only when the aircraft reach sufficient altitude and distance. That's easy to do with the Vessel switcher.

Sorry, I thought that with competition mode and/or vessel switcher available, time to min altitude wouldn't have to be the deciding factor in these battles.

We love you Thanks for the time you put into our entertainment, and I guess your own too.

Very nice battle. It was longer than some but filled with action, interesting to the end.