Orbital Vagabond

June 23, 2015

Now that we have reasonable methods for heat management, I'd rather the devs added a size 3 fission reactor instead of a larger battery pack.

June 22, 2015

I use both - on my launching stages I tend to fire in the hole, but if the stage will be activated in space i tend to stage it separately.

This is what I use. The fewer actions I have to take and fewer issues I have to attend to during launch, the better. I can focus on my trajectory that way. I also use fire in the whole for 2-stage landers. This way I can:

1- Deactivate the landing engine

2- Throttle to max

3- Press spacebar once

4- ???

5- Profit Orbit

In space, I take my time, so engines aren't activated after stages are dumped. In fact, I rarely activate anything via staging in orbit. I almost always right click.

June 22, 2015

What hype?

This hype:

heh, I thought my ears were burning.
It's a small thing - but super cool, and thrilled we were able to get it green lighted for 1.0.3 - it's something I had been tinkering with in anticipation of a future release, but I'm pretty pleased with where it landed, and have been doing a ton of personal playtesting in my own save for the past month or so. I think folks will be pleased.
Oh... and there was a hint in that previous statement. Let the speculation begin.

Yes, they've done worse, but I just have so little tolerance for their hypebait anymore...

I will say that I am happy they're tracking internal and external heat separately.

June 22, 2015

The radiators are the only new part I can find... Is this what the hype was about?

June 22, 2015

I think the frustration surrounding the 1.0.3 issue on BOTH sides should be pretty clear when you look at what has been said about it:

May 19 (Tuedsay): Max states on twitter the patch is coming later this week.
May 22 (Friday): Max says on twitter it's not coming this week... no kidding. Also calls the community savages. Lol, or something.
Nothing the following week except Max states on Twitter "we're working on it"
June 2 (Tuesday): 1.0.3 goes into "Long experimentals," as per Max in the dev notes. Won't see release for at least two weeks.
June 9 (Tuesday): 1.0.3 "doing well" and new features being added.
June 16 (Tuesday): Two weeks after "won't release for at least two weeks" we get... PS4... and nary a mention of 1.0.3.
June 19 (Friday): 1.0.3 due out next (this) week, and Kasper can't comment on what's in it.

So, Squad is actually doing a better job than they have in the past because they've actually said *something*. Last year, they basically went months between telling the community anything other than how awesome they were.

However we still don't know whats even *IN* patch 1.0.3. Is *still* it supposed to be an aero re-balance? Does it fix the memory leak? Why can't Kasper comment on what's in it, or at least what's planned to be in it. Oh, but it has Roverdude's new secret "THING", it it...

So yeah, we get frustrated because the game has problems. Literally game breaking problems. And the publisher won't even tell us if they're fixing it this patch or not after stringing us along for a month.

That's bad communication, and it's making people frustrated and angry.

June 22, 2015

So, it's okay for us to criticize and be snarky, but they can't be even somewhat mildly ironic? How was that 'harassing'?

There are (or at least should be) very different levels of acceptable behavior between the typical community members and moderators, especially the 'official' blue mods.

Personally, I found sjwt's post to be straight up rude and belittling to Mandelbrot's reasonable comment, so I said something.

June 22, 2015

Kasper's the Lead Moderator, the Community Manager position is currently vacant. He is a Squad employee, though.
Squadcast has never been done by a developer (aside from the big team meetup a few weeks ago in Mexico, everyone was there then), usually it's MaxMaps doing them, who is a producer rather than coder.

I would consider the producer part of all of the teams, since it's my understanding he oversees all the teams.

The point here, though, really was the summary didn't make it sound as if Kasper was particularly knowledgeable about whats going on, so why was he doing the Squadcast.

I guess "he's an Squad employee" is the reason.

- - - Updated - - -

you have caught us out, we fixed the memory leak and now have been sitting around doing nothing and will be waiting until 2016 to realize it, no other changes have been done, or worked on.

Man, c'mon! Is it really fair to harass community members about legit questions re: upcoming patches for known issues when the devs/producer haven't been very forth-coming discussing it?

June 21, 2015

Few questions about the legality of using KSP brand images in third-party videos. I know I've seen people use KSP brand logs at the start of their videos.

Specifically this image posted on these forums here.

I've looked and haven't seen any where any you-tubers attribute the image source or artist, though that doesn't mean that's the "right" way to handle it and the attribution may be in locations I haven't looked.

I understand that the music produced by Incompetech is "royalty free" and you can choose the license you use from their(his?) website, which gives *very* explicit instructions about how to provide attribution. I'm wondering if Squad has a KSP branding kit that gives similar guidance.

Their FAQ states: "We just ask to be given credit, a mention and a link to our website is enough. You must also make it perfectly clear that we are the copyright holders of KSP." Is statement a la "Kerbal Space Program/KSP is copyright of Squad", with a link, sufficient?

Finally, the FAQs state that it's okay to monetize KSP videos, but the forum rules (Specifically 2.2.i) state that links projects for profit are forbidden. Does this include monetized videos? Again, I know lots of people link to videos by Scott Manley, Cybutek, etc, but that doesn't mean it doesn't violate the rules.

Thanks in advance for any informed responses. I want to start a tutorial series, but I really don't want to get harassed/sued by Squad if I express an opinion that they don't like about something.

June 21, 2015

Thanks for the replies. So both of you believe that its slightly more efficient to enter into an orbit before landing. I also agree that it easier to land from an orbit as you can take it slow.
Also, it seems that the difference in landing direct vs from orbit compared to ascending direct vs orbit is much smaller due to the required horizontal deltaV kill and the shorter descent time under gravity. So much so that landing direct vs from orbit isn't discernible.
I love orbital mechanics. Thanks for improving my understanding!

It's true that going to orbit first is slightly more efficient for Mun, compared to a vertical ascent (BTW "Direct Ascent" is not a correct term for that trajectory).

However, as the body's gravity increases (e.g. Tylo), the difference between the two methods increases as well, with the parking orbit always being more efficient.

This has been discussed in some depth in a very recent thread here.

June 20, 2015

Step 1 remove air friction. Do an instant horizontal burn at KSP and a second instant burn at AP to circularize.
A: 4641.55 m/s (Orbital Vagabond)

I never said anything like this!!! The only dV estimate I provide was half this value!

I can tell you that a Hohmann transfer from 70 m (about where KSC is) on the equator to a 75 Km circular orbit would take 2389.9 m/s, assuming infinite TWR and no velocity losses due to drag.

I'm really kinda starting to regret even commenting on this thread...

June 19, 2015

Isn't Kasper, like, the community manager?

Is there a reason we're not getting devnotes from someone on the dev team?

June 19, 2015

Which is exactly the relevance. If you followed my post, it was a reply to the "realism" argument, which is often a defense for the "this feels cheaty" argument. Using words like cheat, cheating, cheaty connotes that something is "bad", hence the desire to defend against this. You simply could have said MJ does not fit your playstyle and leave it at that.

Other people have opinions.

They will use the words they find most appropriate to express those opinions.

My opinion that I have chosen to express using the words I have chosen to use offers you no offense, nor justification for hostility towards me or others.

There's nothing for you to defend, as neither my opinion, nor it's expression have any impact on your or how you play the game whatsoever.

Deal with it.

Another reason I prefer KER is that I can point at it and state without hesitation or qualification "This mod should be stock with no changes in it's implementation". I absolutely cannot and would not say that about MJ. You're welcome to focus on that part of my opinion and ignore my other posts.

June 19, 2015

It never was, though the number of scenarios where other engines are better has increased.

Yes, you can nit-pick that my statement wasn't perfectly accurate, but the old nuke design was so overwhelming superior the statement does stand.

Agreed, there's a niche for almost every engine now.

It's objectively a better game state and this is largely due to the beating the crap out of the LV-N with a nerf bat, though other changes helped.

June 19, 2015

Wow, and point made one post after mine.

Yes. My post was one after yours.

Why do you point that out? What relevance does that have? Is my statement that I prefer KER over MJ is somehow less valid because it was posted after your post, instead of before it? Also, your post seems to focus on the realism aspect, which I never mention.

I assure you, your post was not there when started to draft my post, hence my post is in no way a response to yours.

I also clearly stated I found MJ cheaty FOR MY PLAYSTYLE. You seem to be equating my preference for my PERSONAL playstyle to judgment of OTHERS playstyle, even though I included a clause to avoid such an interpretation.

If you're offended by my post, or think my post was in some way designed to address you specifically, then you are mistaken. If you are somehow offended by the content of my post, then you seem to be looking for a reason to take offense from a post where there was clearly none intended.

I'm frankly confused how you think my post has anything to do with yours.

The beauty is that you don't have to use any of the automation features on MJ if you don't want.

If I have one package that provides what I want and need with no extraneous material, why would I forgo that and use another package that provides what I want and has tons of extraneous material?

The beauty of KER is that I want simple readouts, and only simple readouts, and then KER gives me simple readouts and only simple readouts.

There's also VOID.

VOID runs on KER, and I used it for the longest time until KER started to provide HUD displays. I also had issues with VOID resetting window locations and font sizes. Never sure if it ever got fixed, but I found I prefer KER.

June 19, 2015

I use KER. IMO, the data provided KER is needed to intelligently play the game. KER provides this information, and does nothing else. Which is perfect. I prefer minimalism.

From what I've seen, MJ provides the data and then does tons of other stuff as well. IMO, all the extra stuff in MJ is extraneous.

I also think MJ is too 'cheaty' for my playstyle. It automates too much.

June 19, 2015

[h=2]Please explain to me, what all the LV-N hype is about?

[/h]

Sure: Pre-1.0, LV-Ns handily beat basically every other other engine for efficiency.

This changed in 1.0, and now some players are disappointed that "Use nukes" isn't the answer to maximize dV in every case.

The game state now is better for the change, and people will get over it in time. 1.0 also nerfed some other engines like the 48-7S that ruined similar "use this for everything" situations.

June 19, 2015

Originally my plan was to attempt to define everything in terms of r (isp, air density, flight angle, velocity, thrust, acceleration of gravity) Then integrate that from 600,070 to 675,000 with an initial condition of V₀ = 0 and V_f = 2287 in the horizontal direction. The big problem comes from drag which is not directly related to r and the fact that I do not believe the wiki has been updated for how the new aero model works

Might I suggest you try modeling everything in terms of time? In my experience, it works much better since you can model r in terms of t, and then all r-dependent factors like drag and ISP in terms of r.

June 19, 2015

Oops, good point there. I was getting a bit fast and loose with the terminology.

Just had to say it. I thought it was especially relevant to make the distinction since the thread started on one (LOR/EOR/DA) and moved to the other (Vertical ascent).

Also, I clearly confused myself a little and attributed too much to the Oberth effect. There is some oberthage going on, as an orthagonal burn escape does do its burning close to the surface and thus deep in the gravity well, but yeah, the main savings is in mostly ignoring gravity. Once you're safely falling around the mun, every kN of thrust goes into your escape, while on a vertical ascent, you're spending your might on holding yourself up on a pilar of flame, and only get to keep the difference.

Yeah, the difference is ultimately not that great in the case of the Mun. Other bodies aren't so forgiving though.

Anyway, to put it briefly, yes, straight up there are gravity losses. But those are minimal on Mun, so if you're on the side that's retrograde with respect to Kerbin orbit, the amount you lose to gravity is less than would be needed to orbit before ejecting.
I didn't do any math, mind you, just experimented a bit. May vary with TWR, for instance.

I would refer you to the videos I linked in my previous post. They provide evidence that directly contradicts your statement that gravity loses are less than "wasted" prograde dV.

You lose more going straight up than you lose going into orbit first. The statement you're making (Vertical ascent suffers less losses than a parking orbit) doesn't stand in either theory or practice. Differences are small, but the vertical ascent is not the more efficient of the two, and it never will be. TWR will reduce the difference, but it will never cross the line.

June 18, 2015

This is kind of a pet peeve, but the terms "Direct Ascent" and "Vertical Ascent" aren't interchangable. Direct ascent describes the mission profile for landing the whole ship on the Moon, not how that vehicle takes off. Direct ascent is in contrast to Earth Orbit Rendezvous (EOR) and Lunar Orbit Rendezvous (LOR) lunar mission profiles. Vertical ascent is a way to get off the surface. A vessel on a "Direct Ascent" mission could take off into a vertical ascent trajectory, or a go into a parking orbit first.

As a note: The LOR profile won out for the Apollo missions because the direct ascent would have required a vessel larger than what NASA could build (Von Braun's 'Nova' rocket) and the EOR mission was too complex (one study estimated it would require 10 or more Saturn 1 launches). The Soviets probably would have used the EOR profile. In KSP, the weight savings in fuel of the LOR mission to the Mun is really ouweighed by the increased weight of the lander you have to shuck out to the Mun. Hence, the direct ascent profile has become a popular choice.

Also, I found the thread where I saw those videos posted. I'm NOT going to provide a link to the thread though, because it got extremely toxic. Best to leave that trash buried.

June 18, 2015

Yes, yes, but WE AREN'T GOING TO ORBIT. The most efficient way to simply leave the gravity well is straight up, max thrust. All this Pythagoras stuff is about developing a sideways velocity vector so that you can orbit. If you never intend to orbit, that's just wasted delta-v.

This completely incorrect from an orbital mechanics perspective. In fact, this is the least efficient way to break out of a gravity well.

Some proprotion of dV spent thrusting along the radial direction (e.g. "straight up") is lost due to gravity acting in opposition to the thrust (I refer to this as gravity drage, but some other people might disagree with that term. It's not important). Thrusting perpendicular to the gravity vector (e.g. a gravity turn) mitigates losses due to gravity.

This can be demonstrated in a simple thought experiment as follows:

Someone up above pointed out that "Escape velocity is escape velocity" (Escape velocity is actually dependent on altitude, but we'll let that slide for the moment). Also, Fuel consumption and thrust are constant over time.

When acceleration is parallel to the gravity vector, acceleration due to thrust is reduced due to gravity, as in a "straight up launch".

When acceleration is pependicular to the gravity vector, acceleration due to thrust is not reduced by gravity, as in thrusting to a parking orbit.

The vessel thrusting "straight up" will have lower acceleration than the vessel thusting perpendicular to gravity. Hence, the a vessel on the "straight-up trajectory" will have to thrust for more time than the vessel on the perpendicular trajectory to reach escape velocity. More time thrusting directly translates to more fuel consumption.

The parking orbit also provides some advantages to the straight up trajectory, in particular you can select your ejection angle; You can't select your ejection angle when launching straight up from a tidally locked body.

I say "from a orbital mechanics" point of view, because there are a few things that can influence empirical results. First, high TWR and high velocities well in excess of escape velocity can mitigate those loses (greater speed leads to less time in the sphere of influence, reducing gravity drag). Very high TWRs are relatively easy to attain on low gravity bodies like the Mun and Minmus. Also, a straight-up trajectory reduces the amount of time the vessel suffers from atmospheric drag, which may influence empirical results when taking off from Kerbin.

Addendum: On this comment...

I'm asking, from that spot (facing retrograde), is there any trajectory that gets you back to Kerbin better than just straight up? I think not.

There's a pair of videos videos demonstrating the difference between these two approaches from the Mun

. The vertical ascent was slightly less efficient than the parking orbit (878.7 m/s compared to 855.3 m/s).

June 18, 2015

But as soon as it docks, it goes right through the floor of the cargo bay.
Any ways to prevent this?

Try placing the docking ports on the top of the cargo bay so the rover "hangs" from the top of the aircraft.

The rover is [probably] falling through the plane because you're relying on the plane's floor to hold it up. This won't work because the when the rover docks to the plane, they become one vessel, and vessels can't collide with themselves. hence, the wheels on the docked rover can't collide with the cargobay of the aircraft because the rover and aircraft are one vessel.

But You don't provide pics of the problem occuring, so that's all speculation

June 18, 2015

But you do not have a 70mx70m orbit at launch time.
KSC is not moving at orbital velocity
So you need to add the circularization burn to your dv requirements. :-P

The dV estimate I provided assumes a prograde velocity of 174.6 m/s, which was calculated based on Kerbin's radius, rotational period and KSC's elevation. The speed can be confirmed by parking a vehicle on the pad and switching the navball to "orbital" mode.

Edit: A now removed post brought it to my attention the original remainder of this message (which I have voluntarily removed) may have been unnecessarily harsh. Frankly, I found the rebuttal cited above to be quite rude and snide, as it not only criticizes from what appears to be ignorance of the calculations I performed (i.e. no clarification was requested, nor was any evidence provided for a counter-point), but the smilely and tongue smileys were also quite disrespectful given the calculations were accurate given the cited assumptions.

When criticisms, such as is quoted above, are made without full understanding of what was presented, it doesn't help the conversation. It only muddies the waters and confuses less well-informed readers.

I would really prefer it if, in the future, you could just ask about what was done before posting what you think were needed corrections.

/soapbox

June 17, 2015

Should I go for duna or eve first

If the choice is Eve or Duna, I'd recommend Duna. Eve's *technically* closer (takes less dV to transfer to Eve), but it's harder to get back. Duna is all-around more forgiving and you may be able to include a lander.

However, Gilly (Eve's moon) is SUPER easy to play with, land on etc. I still think I'd recommend Duna first if you're just starting out though.

June 17, 2015

It's Minmus so it'll take almost no fuel to hover. Build a skycrane, grab the cupola, and get it back up into orbit.

June 17, 2015

Why are all the choices variations of openGL problems? I don't see one for increasing allowed memory usage for more mods.

Profiles

Forums

Developer Articles

KSP2 Release Notes

Bug Reports

Posts posted by Orbital Vagabond