natsirt721

This guy gets it. I came to this thread to make exactly that point, but it seems my work here has been done...

Could you clarify the point? There were a few questions in there, and I tried to answer the title question as best I could. Most of the fluid that fills the space beneath the object as it ascends doesn't come from below, it comes in from the sides. Some fluid travels upwards with the object, as friction between the fluid and the object imparts some momentum on the fluid, but the fluid is always moving slower than the object, and compared to the size of the object the total volume moving upwards is significantly less than the displaced volume. Yes, the water that fills the gap can accelerate faster than a gee, the acceleration depends on the water pressure and the speed of the body. If the body is going fast enough (or the fluid pressure is low enough), the fluid won't be able to accelerate fast enough to keep up, and you get cavitation, where a vacuum (or rather, rarified pocket of water vapor) forms between the water and the body itself. As for the title question, there is no definitive answer. The actual peak acceleration due to buoyancy depends on several factors, namely: The geometry of the object The mass of the object The density of the fluid

This is sort of a meaningless question, and I'll try to explain why. Buoyant force is based on a pressure gradient, and drag is based on velocity, ergo the maximum acceleration will be when you first let the object go. If the pressure gradient is extreme enough (read: if your object is tall) then this force could be pretty significant. I wouldn't consider the air inside the object as a fluid, and instead consider the entire thing a solid body with a given density. Example: 1 meter hollow aluminum cube, wall thickness 1cm = ~200kg. Force on a side = Area * rho * g * d, where d is m from the surface. Force on the top = 1m2 * 1000kg/m3* 9.81m/s2 * h, force on the bottom = 1m2 * 1000 kg/m2 * 9.81 m/s2 * h+1 (cube is 1m tall so the bottom is 1m lower than the top). Subtract those to get the delta, h cancels, force delta is 9810N up. Gravity is 9.81m/s2 * 200kg = 1960N down. Net force is 7850N up, which for a 200kg object provides an instantaneous acceleration of a = F/m ~= 39 m/s2. Of course, this is only valid for the exact instant you release the cube, as soon as it starts to move you get drag effects, and the cube will probably start to rotate and the force delta will decrease. You can increase this by increasing the height of the body, and by reducing its mass. So, maximum acceleration is about 4 gees, but you're only going to do better than a gee for, say a second or so. At that point, your velocity through the fluid produces enough drag that the forces are balanced and you ascend at a constant velocity. This velocity is largely dependent of the ballistic properties of the object, and I won't attempt to derive the value for the example above.

Ah, so it is. I thought animatter had a better energy density than that (truth be told I was paraphrasing a novel and didn't bother to verify, dammit Niven!) bingo

Alrighty, lets see here. First off, I don't recommend using antimatter for surface-to-orbit, because of two reasons. One, a single kilogram of antimatter, when annihilated could easily destroy the moon and probably sterilize the Earth too, so if your launch fails you better have a plan to keep that antimatter safe as you plummet back to the ground. Two, antimatter annihilation produces lots of gamma rays, which will basically kill anything living nearby which isn't properly shielded. Not so great to do on a possibly inhabited surface. Take a look at this 'realistic' antimatter engine for a sense of scale. But screw that noise, you want an engine, dammit! For liftoff, we need a TWR of about 1.2. 97 kilotons with a TWR of 1.2 makes for an thrust of about 1.15e9 Newtons. Antimatter reactions produce their energy with about 1/3 gamma radiation and 2/3 charged pions. Lets ignore the gamma radiation and focus on the pions, because they're charged so you can move them around with magnets and harvest their energy. One gram of matter annihilating one gram of antimatter makes 1.8e14 joules of energy, times 2/3 for the pions makes 1.2e14 J. The pions are moving at 0.94c, so we can just blow them out the back of the spacecraft and call it thrust. Thrust power = 1.2e14 J/g * antimatter mass = Thrust * Exhaust velocity * 0.5. At 1 gram per second our thrust is 8.53e8 N. Not bad for a conventional engine, but that ain't gonna cut it for our ship. Fortunately, we can increase the thrust by adding LH2 and reducing our exhaust velocity. This is where the engineering comes in. We basically pick the exhaust velocity such that we don't use too much antimatter, and we don't need too much LH2 Pt is thrust power, W 1.2e17 is antimatter power production per gram of antimatter J/kg mdota is antimatter consumption rate, kg/s T is engine thrust, 1.15e9 N Ve is effective exhaust velocity, m/s mdotLH2 is LH2 mass flow rate kg/s For a Ve of 100,000 m/s, our thrust power is 57.5 TW, which is 4.8e-4 kg of antimatter per second, or about half a gram per second. LH2 consumption rate is 11 tons per second. For one liftoff/touchdown cycle (call it 20kps without aerobraking) you need about 18 kilotons of LH2, or about 20% of your initial mass. You're probably going to want to land in the ocean, because 57 TW is going to pretty much destroy whatever is under the drive when you touchdown. I'll leave it to you to increase your Ve until you get numbers that you like. And, if you have antigravity, you can crank the thrust way down and get better performance.

I understand the concept of a three-burn phasing intercept, but in cases where the semi-axis ratio is less that about 12, (starting to destination) the bi-elliptic transfer has at best equal performance to a direct transfer, and inferior performance to a pure hohmann. From wikipedia: Now yes, if you're trying to do a pure hohmann from Kerbin to Moho, you're going to have a bad time because hohmann transfers assume the destination is coplanar with your origin, and you're going to pay dearly for a 7 degree inc change in heliocentric space. But that's just a lack of understanding of when to use a hohmann transfer - you should be using a Lambert solution for complex transfers like this. I tested this in sandbox, executing the kerbin escape burn and using nodes to SWAG the rest of the flightplan. Starting from a 6,000km circular Kerbin orbit and resulting in an inclined 30km circular Moho orbit, the three-burn approach took about 320 days and cost this much: Burn dV Kerbin Escape 1517 Course Correction 53 Perihelion Phasing Burn 1162 Moho Insertion 2583 Total 5315 The perihelion burn was the lowest dV cost to achieve a one-period Moho intercept. I could have reduced my aphelion further to reduce my insertion burn, but I'm not going to save thousands of m/s by burning at perihelion rather than at Moho. Like my previous post postulated, this method was technically very easy to execute and required little to no fiddling with nodes to achieve intercept. The direct lambert transfer took about 95 days and cost this much: Burn dV Kerbin Escape 2493 Course Correction 55 Moho Insertion 2805 Total 5353 The planner I used put my transfer ellipse at a 5.5 degree inc w.r.t. Moho and about 8.7 degree inc w.r.t. Kerbin. It estimated the total dV cost at 5316, which - allowing for course correction and steering losses - is pretty much exactly what the nodes give. Energy is energy, and in a two-body environment there isn't a lot you can do other than pray to lord Oberth and burn at your maximum velocity. Adding the phasing burn makes the other two more mild, but at the end of the day, you still need to affect a total change in energy to capture at Moho. You're not going to oberth your way out of 40% of your energy costs, at least not for this transfer. I think we can both agree on one thing though, and that is you shouldn't use a hohmann transfer to get to Moho.

I would appreciate the utilization of this system in stock, but in a slightly different manner. My line of thought applies to engines most directly but can be applied to other parts as well. First, upgrades aren't mandatory. Similar to Zoo's suggestion, science points and funds (R&D effort) can be spent to apply upgrades to parts in several categories depending on the part, and each category affects mass, cost, and other related category values based on the category delta from the reference part. e.g. increasing ASL and vacuum iSP for the Reliant might not affect mass (engine bell geometry), but thrust would suffer because m-dot is the same. Increasing m-dot would increase mass due to a better turbopump, and might reduce iSP slightly. The amount of delta in each category is capped (as a balancing mechanic) and can be increased as the new tech nodes are unlocked. Once the part has been 'tweaked' and the R&D cost assessed (again based on the delta from the reference part), the part gets a new mode, or simply a duplicate model with different stats in the editor. This way, the player gets to decide how to apply upgrades, and they aren't stuck with precanned benefits or detriments, and they can have multiple variants of each part optimized for different roles. This could be a royal pain to implement though, because not only does each category of part need its tweakable parameters and their effects on other parameters defined, but the ranges have to set and balanced for every part. A graduated slider (1 or 2% intervals) of upgrade might make this easier. Structural parts and tanks would be pretty easy, but engines and wheels could get complex. I would also like to see some default acceleration and thermal tolerances reduced to make reducing mass actually have noticeable detriments (default impact tolerance balance is probably fine). Fuel tanks cannot withstand multiple 10's of gees without failing, no way. Al-6061 starts melting at 880K, not 2000K.

Wow. That is...brilliant. I'm going to use that extensively for my OPM orbiters.

@Geschosskopf While your tactic might make it technically easier to execute, I don't see that it actually saves you any dV. The launch planner I used correctly gave the the transfer and injection burn vectors, which I agree were significantly higher than the dV map said, but that's why I used the planner instead of the map. I would expect that the intermediate burn to bring your aphelion down to phase with Moho makes up for the injection dV. Although, there are probably some savings from staying coplanar with Kerbin. I'll have to try it next time I need to go there.

This fine morning I was attempting to send a mission to Moho. I fired up AlexMoon's transfer calculator and found a dandy transfer the mercurial planet. Plugging the escape velocity into my maneuver node I looked at the closest approach indicator to Moho. 12e9 km?? That's not right? I fiddled with the time and burn vector a bit but I couldn't manage to make it anything less than 1.9e9 km. "Something's not right here" I said to myself, "AlexMoon's a smart dude, he wouldn't lie to me like that". So I started thinking, why would my closest approach indicator be incorrect? The conclusion that I arrived at was that the indicator finds the first local minimum distance from the maneuver rather than the global minimum distance. "Gee, that's pretty annoying, the indicator should probably search one full orbital period and show the minimum for that time, not just search until a local min is found," I said, "In general, the method works fine, but once you start using non-hohmann transfers where the relative geometry of your spacecraft and the body becomes more complicated, it completely breaks down." Then the epiphany hit. The indicator always shows the local minimum after the last node on the plan, the same way that the node line indicators do. Could I trick the game into searching further in time by placing another maneuver node with no dV later along my path? As it turns out, I could. By placing an empty node past the reported time of closest approach and sliding it along my planned trajectory towards where I expected the encounter to be, the closest approach indicator jumped to the new node and followed it all the way to the encounter. By setting the time of the dummy node directly when I expected to arrive at Moho, it was a trivial matter to tweak the burn vector and time to achieve an encounter. I suspect that this tactic will also work for vessel-vessel transfers, but I have yet to implement it there. Note: This was achieved with an old game, and may not even be applicable for new versions.

No, its always been kind of a cluster... @DerekL1963 @Fraktal this discussion is about stock science settings - DerekL is correct in saying that your personal gripes with your choice are not relevant to the discussion at hand. That being said, Fraktal's comments about being 'stuck in a gap' are indicative of imbalanced science gain in the early-mid game, a sentiment I have seen expressed in other places as well.

I was going to wait for a few more people to respond before drawing conclusions, but this sums up both what I expected coming into this, and what I interpret from the results so-far. If that makes this poll somewhat self-indulgent, well, so be it :p. As the results have been coming in I've been formulating what a rework would entail and how to do it right - this started out mostly as a comm-net rework in my head, but my thoughts on that would involve rebalancing science gathering, so here we are. I especially agree with your distinction between transmissible and processable experiments - the current transmission efficiency model, while somewhat effective, doesn't really make sense to me. Instruments produce ones and zeros, and lossless digital data transmission is a thing, as long as you are willing to wait long enough. As you note, this simplifies a 'run all - send all' interface to mitigate the clickfest, and emphasizes multiple missions for unmanned landers, sample return missions, and crewed missions. As far as time-based mechanics are concerned, my conceptual rework will hopefully address this. I recall reading a post that said that HarvesteR was opposed to wait based mechanics, but not time based mechanics. Currently, my solution involves exponential curves, data rates, and significant EC costs, but I'll elaborate on this later once I sort out the big picture. On the surface, I don't seem to like the time-based milestone system - however it is definitely food for thought. Perhaps it could be integrated with the persistent milestone system like someone (the name escapes me) suggested previously. The tech tree could use some work. I agree with the 'wider, not deeper' attitude, and will probably sort something out based on current examples.

You make it easier to acquire some science, but harder to acquire lots of science.

My advice here is: don't land with the brakes on. Wait until your aft gear are solidly down, then active the brakes. If one wheel touches down first, with brakes that is going to apply a good amount of torque to the airframe before the other wheel touches down. Aircraft aren't nearly as stable in the yaw direction, especially at low speed, so it doesn't take much of a disturbance to induce a spin. Edit: did not check the timestamps, hope this thread isn't too necrotic.

KSP Explanation: Vessel specifics (i.e. what parts are where) are stored in a file and bending is caused by the physics engine. When you switch to a nearby part, your vessel can get 'packed', which is like being in warp but not exactly. When you switch back, you get 'unpacked', where the game loads the vessel data from the file again. On packing, things like joint bending data are not stored, probably because a) a pilot seeing bending will stop doing whatever he is doing, because bending leads to breaking or b) aforementioned bending is about to become breaking. So, on unpack the vessel maintains its orientation but all the parts go back to their 'proper' places, i.e. how they are defined in the file. Science Explanation: Bending of structural components is not inherently a bad thing - in fact is is an unavoidable consequence of loading (applying a force, not saving/loading) a structure. At low stresses, the components bend 'elastically', that is, they will return to their original length if they are unloaded. At high stresses, they bend 'plastically', and will not completely return to their original length. What you are describing, plastic deformation - or saved part rotation - is VERY VERY BAD for structures, because every time it is stressed and unstressed the part gets a little bit longer (if loaded in tension) or shorter (if loaded in compression). As parts/structures are usually composed of multiple beams, forces will cause some beams to elongate and some to shrink. The beams that elongate still have the same amount of material, which means that their cross-section (and their ability to resist loadings) shrinks - this will cause even more elongation the next time the same force is applied. Eventually, load/unload cycles will cause the beam to be loaded beyond its ultimate strength, at which point it fails. Oh, and welcome to the forums

Not a bad solution, but the difficulty lies in defining 'stagnant' in game terms without a byzantine set of conditionals. Well, that's quite the fatalistic viewpoint, but one you are entitled to, certainly. I think the one thing we all can agree on is that there is no golden hammer solution. I would also think - hence this poll - that a significant portion of the community has at least some gripes with the current system. If we can find some things that many people agree should be changed, then by all means some progress - be it by Squad or the community - can be made to better the experience of everyone.

The problem with pure science per day is that there is nothing stopping one from setting time warp at max and going out for dinner. You should still have to work for the science.

Something to keep in mind is that experiments have a hard cap on their maximum return. E.g. the goo has a base science of 10, but a max science of only 13. On Kerbin (0.3x) this yields 3 science, but on Minmus (5x) this only yields 13 (caveat: since reading the wiki article I have not tested this). The largest base:max ratio seems to be the IR telescope at 1.43x. The fact that these large integer multipliers exist, yet don't seem to have significant impact is another example of poor design.

This is good for systems where you constantly earn science, but in KSP you mostly get science in chunks whenever your missions reach a new place. I don't really see the difference between 'selecting tech -> earn points -> get tech' and 'earn points -> select tech -> get tech'. The second part of your comment I like, but in order for it to be implemented I think the science points would have to be divided into classes of experiment with each tech having a number of points from each class. In this way, you could select which node you want to invest which points in, and also couple exploration more directly with the rewards you recieved. e.g.: tech nodes with structural pieces would require more points from materials studies or surface samples, whereas tech nodes with aerodynamic components would require more points from atmospheric samples and barometer scans.

This would imply a passive science gathering method? What about a 'toggle on' at the start of the flyby and a 'toggle off' when you're done, and the actual collection is automated? I hesitate to endorse a totally passive system but I agree, the current system has too much micromanagement of sampling for my liking. Edit: by this, I mean the instrument would have an 'on/off' toggle which would automatically collect science and consume EC while it was on, and create the reports for any science gathered when it was turned off.

Great feedback, adding to poll

That is an interesting observation. The implication with the stock cycle is new parts -> more accessible locations -> mission -> science returns & research-> new parts etc. The problem is that the cycle is that the following usually occurs: mission start -> new place -> science & research -> mission end, new parts, wait for a while for the next mission. It looks like the disconnect is that between missions, nothing is actually being accomplished - the only way to progress is by perpetuating the cycle and constantly doing missions. This to me implies that some sort of science over time mechanic (based on your achievements) is necessary to make it seem like the time between missions is actually worth something. @DerekL1963 Those are some good points, and I agree wholeheartedly with your comments w.r.t the poll options - the beauty of this game is that you can play it how you want. However, more than any other 'problem' (perceived or real) with KSP, this one seems to be the the most ubiquitous and the easiest to implement a fix for. This isn't a poll about 'what do I do to make the game fun for me', it's a poll about 'what is fun/not fun out of the box'. The issue I see is that the career mode in its default state is both a) restrictive for new players with little knowledge of space mechanics but want a sense of direction in their gameplay and b) not challenging enough for veteran players without self-imposed restrictions. This to me is the exact opposite of how a 'career' mode should operate - it should provide a challenging experience for players across the board, and meddling with science/cash/rep multipliers seems like a quick and dirty solution on the devs' part. Some tweaking is of course necessary - I don't expect a one-size fits-all solution to single-handedly revitalize career mode - but the current distinctions between easy and hard are almost negligible. Maybe hard mode should ship with a 30% science multiplier, I don't know. Either way, thank you for the feedback.

Over the years, there have been many airings of grievance regarding the science system in career mode. With this poll, I hope to collect a sample (albeit a limited one) of the community's misgivings with the way the science system functions. With this data, I and/or others may attempt to pose a satisfying solution either to be created by the modding community or posed to the development team as a stock mechanic rework. This poll was created based on my own experience with career KSP and about two hours of googling. If you think I have left out a grievance leave a comment, and I'll add it to the poll. Edit 10/25: Adding 'things are fine' and 'other' options.

Ooh, that is very nice, I'll have to take a look. I maintain that it should be stock behaviour.

Botching a Munar return aerobrake and disintegrating a pair of NTRs in the upper atmosphere. That was bad PR...