Jump to content

Orbital Vagabond

Members
  • Posts

    100
  • Joined

  • Last visited

Everything posted by Orbital Vagabond

  1. 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.
  2. 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.
  3. This hype: 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.
  4. The radiators are the only new part I can find... Is this what the hype was about?
  5. 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.
  6. 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.
  7. 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 - - - 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?
  8. 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.
  9. 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.
  10. I never said anything like this!!! The only dV estimate I provide was half this value! I'm really kinda starting to regret even commenting on this thread...
  11. Isn't Kasper, like, the community manager? Is there a reason we're not getting devnotes from someone on the dev team?
  12. 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.
  13. 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. 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.
  14. 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. 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. 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.
  15. 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.
  16. [/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.
  17. 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.
  18. 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). Yeah, the difference is ultimately not that great in the case of the Mun. Other bodies aren't so forgiving though. 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.
  19. 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.
  20. 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... 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).
  21. 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
  22. 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
  23. 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.
  24. 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.
  25. Why are all the choices variations of openGL problems? I don't see one for increasing allowed memory usage for more mods.
×
×
  • Create New...