PB666

To solve the issue of reality one has to divide reality into two or more groups and try to solve the reality issue. Lets take example of reality that should not be solved in game. 1. Trying to earn the 10 of billions of dollars it takes to run an earth space program. 2. Trying to build the civilization required to support a real space program Other realities to be had. 1. Alter the stature of Kerbals. 2. Increase all the worlds to realistic scales, make the system 10 times bigger 3. Increase the length of the day to 24 hours, the year is then 10 times as long. Realistic build times. 1. Spacecraft take months to be built instead of instantly 2. Transport times to pad take days. 3. Launch count downs that take days. What remains 1. Shift in physics (away from mass based drag toward shape based drag) 2. Fuel density accord to real world. 3. Lift is not a stated value for part but comes as a result of simulated aerodynamics The rockets created by KSP look reasonably decent, IMHO with the latest pack they are getting close to real looking. The space physics is decent, but the SOI takes some of the possibilities Like L1-5 points out for science. And that goes for one of the major issues, given such a lack of realism: What is Nasa and ESA doing. 1. Space astronomy a. Visible astronomy b. microwave, infrared, XRAY and high energy gamma ray ....electromagnetic space astronomy is a large proportion of nasa's budget but almost none is conducted in Kerbal science. This is one of the biggest frustration with the game, I can create huge space stations (capacity 120 kerbals) NASA would be jealous of (albeit not jealous of the lag that goes with them) but there is nothing to do except gravoli, goo, mat sci, and temp. 2. Magnetospheric studies 3. Particle collection and analysis. Here are areas were major additions can be made. If your are a decent rocketeer why do you need engineers, put the them work build a space observatory that would put NASA to shame. They could have images where you hunt in those images to find novel things like GAMMA RAY BURSTS or nebula, black holes, etc gain extra points for each major anomoly characterized.

OK, OK.....Not exactly what you are saying.... Chuck the quantum kitty gets placed on the applicant list. Then I go get a mission (or not) and go to an assembly building, launched........ but there's ole Chucky [psycho movie background music playing], an applicant to be deleted, an active pilot at the same time. What we really need here to make this right is an automated pilot makeover in which the kerbal turns orange and has blood vessels popping out of his skin, mid flight the rocket veers off course and lands in the center of large impact crater on the other side of the Kerbin, followed by a wicked laugh and chucky proclaiming to rule the world......Yes, this would be the perfect bug fix and a new hidden career mode---Insane - world of missilecraft. .....and they are accepting missions for which they had been previously fired ......and showing up on two rosters at one time. Summary: Assuming that these nested bugs are all part of the same phenomena they may begin presenting themselves in various ways. 'Fired' players may be the default crew on future missions, show up on two rosters (active and applicant) at once and other oddities. However eventually they will be deleted and once deleted, because they have previously achieved some past recognition (like landing on an uninhabited volcano, ), lock-up the game on a later facility entry and exit.

This is in response to another post dealing with rooting. In this example demonstrates how to identify and get around rooting problems. This example is a worst case example for rooting since the primary node I want to create is not a predefined node, but it is on a solid surface. Here is the stock parts cfg file: PART { name = Size3to2Adapter module = Part author = Squad mesh = Size3Adapter.mu rescaleFactor = 1 [B]node_stack_top = 0.0, 1.1, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -1.1, 0.0, 0.0, 1.0, 0.0, 3[/B] TechRequired = veryHeavyRocketry entryCost = 8800 cost = 2600 category = Structural subcategory = 0 title = Kerbodyne ADTP-2-3 manufacturer = Kerbodyne description = This adapter is used to bridge between Kerbodyne and Rockomax rocket bodies. attachRules = 1,0,1,1,0 mass = 0.2 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 6 breakingForce = 200 breakingTorque = 200 maxTemp = 2900 } The above part would prefer to attach to the bottom node or alternatively its top node. If you added another node to the top of the bolded list it would basically ignore that node (my experience) for rooting. This part was an ideal starting point for creating a head for a nacell such as a core rocket with three ground pointing nacells. As such it would make an good lander, with wide set feet, but also since the nacells arm would carry fuel, the entire ship can be ported and fuel from a single point (particularly convinient if one has a fuel generator), without the need for dorky looking fuel lines. I wanted to use parts top and bottom node_stack points, and I wanted to add a nacell. This is not what I arrived at however due to the limitations of configuration. This is the part I derived. If you don't want to get into part modding I will summarize, the most desired attachment node is the last one in the list. Others maybe ignored, depending on the circumstances. To understand how to create a new node you have to understand how attachment nodes are defined. In the example above the node is coordinated on the first three coordinates ....... = X, Y, Z. The math is funky and may change with version because of scale factoring so some fiddling may be required. The next three numbers are the orientation of the node = , , , X, Y, Z. These are important in determining the default attachment angle, getting this right makes attachment easier. PART { name = FT50ThreeForthsToOneHalf module = Part author = derived of Squad mesh = Size3Adapter.mu rescaleFactor = 0.23 node_stack_bottom = 0.0, -1.1, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 0.0, 1.6, 0.0, 0.258, 0.965, 0 TechRequired = basicRocketry entryCost = 300 cost = 110 category = Propulsion subcategory = 0 title = Diagnonal mounted Nacell Head, Feuled manufacturer = description = attachRules = 1,0,1,1,0 mass = 0.0270 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 8 breakingForce = 75 breakingTorque = 75 maxTemp = 3500 RESOURCE { name = LiquidFuel amount = 22.5 maxAmount = 22.5 } RESOURCE { name = Oxidizer amount = 27.5 maxAmount = 27.5 } } Note that this: node_stack_top = 0.0, 1.1, 0.0, 0.0, 1.0, 0.0, 2 node_stack_bottom = 0.0, -1.1, 0.0, 0.0, 1.0, 0.0, 3 became this: node_stack_bottom = 0.0, -1.1, 0.0, 0.0, 1.0, 0.0, 0 node_stack_top = 0.0, 0.0, 1.6, 0.0, 0.258, 0.965, 0 The most important line for directing rooting was the last line in the node_stack entry. I did fiddle around with this. I could deal without node_stack_bottom, replacing it with a node starting part, however the node_stack_bottom did not upset the part rooting. Adding another node_stack entry or node_attach disrupted or made difficult the attachment. In this version of the part the top stack preferentially attaches to a radial node. The radial/rooting part should have a node pointing south and the part should approach the radial node from the south for convenient attachment. Fuel parts can attach to the node_stack_bottom. To create a node attachment on the CoG top one needs to use a node starter like modular girder segment (or modded equivalent) and then add nodes to top. Note the stock part copy mod needs a new name name = Altwhatever and new title title = Alternative Whatever . . . . and you may wish to tweek the attach rules. You might not wish to modify your parts, but if you know where in the KSP directory your part is, by looking at the order of entries in the node_ . . . . list you can determine whether your stuff is buggy or it simply will not root through a certain node. If anyone knows of a better way to design this part let me know.

I will address these in a moment First off, I created a new game 'default'. Before doing anything I 'fired' Jeb, he was placed as candidate. On return he was gone. So this checked out. He was replaced by a new named pilot. Next I fired Bob and Bill, on reloaded the 'default' game they were deleted, and two new pilots appears. This checks out. Next I put chuck on a mission, he completed and gained exp, I then, 'fired' him. He went to the applicant section. Without closing the game I then accepted two new missions Erroneously the program autoselected Chuck as the pilot for next two builds, defaulting over the two pilots on the list. On game reload (live KSP) he was still on the applicants list. (which is what I originally expected) I then closed KSP and reloaded. Chuck was still in the applicants list (not deleted) with his experience stats. Chuck, of course, is Shroedinger's cat. Oddly I named my company after him, :^) No but I can rehire chuck, he has not been deleted. And So following this statement I rehired chuck and sent him on a mission. I again fired him, and I again tried to add missions. I managed to remove him from the roster by doing the following, -placing him on the candidates list -in the VAB creating a capsule, then going to crew, removing his name from the MK1 capsule and placing another active pilot in his place. After repeated attempts at trying to crash the game I have been unable at top of tier 3. The rescue mission has showed up . . . . . . . . . . . . at least as far as the game is concerned can be used as a placeholder name for what it actually is, because the observations suggest that it goes undefined. Jeb, Bill, Bob...Bye-bye; Chuck is like a stalking ex-girlfriend..... It should be as such: If firing is true then Kerbals identity should be removed from applicant roster on the next reload no matter what. Shroedinger even confused Einstien god does not play dice with the universe Either the bug is more complex or Heisenberg uncertainty is at play. Does the game employ a random number generator? To summarize, players can't fire kerbs, they can 'demote' them to candidate, and what the game does is delete them. Since the players are not firing them and the game is doing something other than firing them, in essence they cannot be fired. This lack of a definition is the cause of the bug. If demoting is a lead up to firing, then expired kerbs should be relisted, not deleted. This is consistent with the observations, but. . . . . .. I will buy all of this except the fact that firing a candidate does not remove him from potentially active status, he may still default as pilot of the next mission [bug N+1](verified twice). As such he will show up on the candidates list and active list at the same time [bug N + 2](verified twice). This is why there is confusion about activity and firing. Traditionally if one fires someone he is removed from his status he would not be a candidate; instead identified but banished as not to be rehired; this would fix the games problem, creating a term called Banished. In actuality chuck appears to be demoted but still active. If a pilot is fired he should not default to the next mission, even if the game is not closed. I hope you see what I mean by this is a complex and confusing bug the outcome of 'firing' depends on when you closed the game and how long since it was closed or the kerbal was 'fired'. A current build or future build in the VAB should not have recently fired pilot default appear. Since I cannot purposefully crash the game I will restate under what circumstances the game was crashed. Kerbs could be moved from active to inactive status up until some point in the game, in which this or something else caused a crash. Since reinstating Jebediah's profile recovered one game we have to assume that this is at least part of the problem. In the last few games I was playing I was rotating pilots in and out of hired status all was going well until I get to the top of the (45 sci) level of the tech tree. Here is what is observed combined with these, again I did not close the game after every hire or fire because I had no reason to expect this was a problem. 1. Remove the kerbals from active status, put a kerbal with bad stat in. May or may not complete one faux launch for a mission and Jeb Exp. 2. Roam and MK1 roll around KSC gathering science, rolling back to pad to get full salvage. Lots of small sci. This may also include the use of Mat science and goo. 3. level up, using KSC science I usually get two middle of tier 4 (45 pts per) 4. At tier 4 begin going after altitude missions followed by orbital mission. 5. Around this point in the game the lock-up occurs. I cannot say when exactly I opened and closed the game, generally I don't play more than 2 hours at a sitting so I think that the game was closed and opened at least once. Roaming KSC takes alot of time with or without exploits. IMHO, there is something more to this problem than what you have identified and what I have identified, maybe I have to wait a really long time for those timers to expire and crash the game, seems reasonable but not certain. About 2/3rds there, couple more issues that need some work.

The sticky fix repaired the game, but Jeb has vanished, lol. Its not a problem, more than an inconvinience, Even if Jeb has never engaged in a mission, he can never be a candidate, so I guess when I need him I will have to manually 'recruit' him to crews. I don't consider moving him back to candidate status firing him, since he owns the firm. Its like the boss deciding to remove himself from a duty roster. If I want fire him I would make him unavailable. So the exact meaning of these feilds is not exactly clear. BTW, This was done to keep KSC from killing Jeb while gathering KSC science, at least if I was going to kill off a green minion with buggy texture through-falls, it should actually be a minion. (A kerbal with low courage and high stupidity). So let me be explicit, if you move players from active status to inactive status, and they have accomplished some goal (say launched a craft) then while they initially appear to be a candidate again, what they really are is disappearred, since they can never be a candidate, again. This is my emperical observation. That's kind of what is missing.

Its not a bug, if you want to root a part on a given node you have to place it as the last node on the list, and remove, potentially other competing parts, its best to make a new alternative part with new attachment nodes.

I have been directed to the bug fix from one of the threads in the Unmodded section. I have a modded installation but was directed to a bug fix for unmodded install, for this reason I am posting here. In some of the games Jeb was killed after he fell through the KSC terrain (another bunch of bugs). However in a few other crashed games Jeb was not killed, fired or resurrected. I moved him from active status to inactive status, so he would not be automatically pulled for further ground missions (i suppose this is a form of firing, but his experience stats stick with him if he goes on a launch mission), I have been rotating nauts in and out of active status. In most cases for Jeb, this was done at the very beginning of the game, before any missions were undertaken, whereas the game crashes occurs much later in the game after almost a dozen missions have been completed. In all cases except one all pilots were returned home before the next mission preceded. Most games were in hard carreer, however one was normal career (It actually locked up the fastest). For 0.90 I think the sticky needs to be rewritten to deal with the specifics of possibilities in 0.90. This lockup is more complicated in 0.90 than the sticky presents. I have been playing this game for more than a year and I have never experienced this lockup until 0.90, there are specific things happening with this version (either game-controlled, user-input or combinations of both) that would only rarely be encountered in previous versions.

Thanks for the pic, for some reason I cannot upload here. The exact same thing happens to me in Mission Control. Also game breaking, I have tried to run a career 6 times all with pretty much the same result. you've gotten a little further in the game than I have, comparatively my game breaks when I start seeing collect science and rescue kerbal from orbits around Kerbin. - - - Updated - - - I just checked a reply on one of my previous posts, apparently they have a sticky on this in Unmodded report area.

I have had some success finally finding a screen resolution other than 1920 x 1080 that does not flatten objects vertically. The lowest resolution was 1280 x 720 and this sped up the game. I don't have a laptop, I have a Dual core 3 ghz on a Solid state drive and those big stations are stifflingly slow. Albeit I can make stations in 0.90 bigger and more realistic relative to 0.25 and the Karmony modules prolly need to be tweeked . . . . . Before you waste alot of time transferring, have you explored all the new features in VABs translation and rotation modes, I found the stations I could build using these tools a whole lot better designed than in pre 0.90. I have basically dumped all my 0.25 constructs, and also removing alot of modded parts from pre 0.90 simply because with new parts they are obsolete.

Two cents here, I think that 0.90 has a royal problem with Persistent file update on certain events, 32bit or 64bit, the same problem. I can get into the mission control contract center but if I try to exit, the game locks up, this happens after a normal game exit game. I'm on my 6th carreer mode start, I can get to tier three (15-20 sci) technology but thats about it. Hard mode normal mode, doesn't matter. The upgrade preceding failure is the 'rocketry' branch and all the part in mine are stock, so its not being caused by modded parts. Also on my latest save after leveling up 20 sci rocketry i could not go into the VAB; the bug is not consistent. I would say make sure all your Add-ons are updated. Although I did this and it did not work. Make sure all your game saves are normal exits. Again did not work. Make a copy of the game data folder and remove all Addon directories. Going to try this next. Kerbal seems to have forced some into 64 bit, so make sure you are running the 32 bit you installed. 0.90.0 has alot of problems, i've experienced various bugs and I see alot of bug reports here with no responses other than the spurious reply of a person with a similar problem. If you right click on the structure it gives you the option to upgrade, if you have the $Ker$ then you can upgrade the structure, I've only made it so far as to upgrade one structure before my game locks up so . . . . . . . .

I had this happen on restart after patch install, everything got fat. I had to use maximum resolution to get objects to render proportionally.

So many bugs with 0.90 may I should wait for 0.90.1 My day starts with a APPCACHE issue, followed by a rover half falling through the terrain, now this. Problem occurred in career mode hard. After accepting the MK16 parachute mission (2nd of 2 mission accepted) I tried to leave mission control. The other mission was the 33,000 meters mission. Game froze. Alt-F4 repeated and game still locked up Alt-F4 repeated and the game still locks up. Going to play simple rockets on my IPAD now.

Just so as not to confuse folks, the camera switch occurs in my experience when your periapsis crosses between 23,000 and 24,000 meters. Technically that is not an orbit, because on just about any speed craft if your periapsis falls below 32,000 km drag exerts such a retrograde force that the orbit will never again exceed the atmosphere. You could approach at much higher speeds (say 6000m/s) but from the few times I have done this the vehicle goes white hot at high altitude reentry and disentegrates (or undergoes compression g-forces). For the missions orbit is any celestial bound eclipse in which the apoapsis is a positive number greater than atmosphere ceiling (Kerbin = 70k) and the periapsis is also greater than 70k. On the mun it is somewhat different because you could orbit at a low enough altitude that you crash into terrain, there is no atmosphere. - - - Updated - - - 32000 M , not km

Since this has happened twice I figure it is worthy of a thread. 1st Instance Jeb was traveling on foot from the launch pad close to the edge of the zone toward KSC zone at warp 4X and fell through the terrian and was listed as KIA 2nd Instance Rover was traveling toward the tracking center close to the edge of the zone. First one wheel feel through, then a second wheel feel through. The vehicle could not be dislodged even though it could move forward and backwards about a quarter of a meter. it could move in horizontal circles. Escaping to space center only allowed me to abandon the mission and loose the Kerbal. Visually there is no difference between these death-traps and the surrounding terrain, other than being within meters from the edge of some zone.

The word I heard was that the 'risk' exceeds the technology. If you do the calculation and compare risk for mercury/apollo phase and risk in the shuttle program, both for launch and reentry, the known risk have always been present, and despite disasters, ultimately acceptable. An unacceptable risk falls into the category that is probably best described as a suicide mission. So that the second aspect, the technology, needs to be probed. Guessing I would say that if you probed the NASA planners they would confide that there is not a complete set of technologies that gets healthy nauts to mars, more importantly safely and relyably lands into a high-g surface with low atmospheric breaking. The problem gets more 'suicidal' when one figures in the fact there is no known method to return living animals from the surface of Mars. If you can't return nauts from a landed mission, then overtime it becomes linearly more difficult to keep them alive, at such a point where it is either financially or technically impossible, the suicide mission is complete. There is no 'earth-like' planet, and even in the closest approximation Mars falls short of the light, pressure, and gravity needed to sustain life. As each of these deviate from Earth's the cost of technology needed to support life increases. Whereas you want to keep your nova-martians alive you need a space-station in orbit, low cost supply ships, something that can target the base, land successfully at 100 m/s (therefore not needing to burn) and some means of cheaply deorbiting it. Grow the food in orbit and supply the base nutrients either from comet mining or from Earth, but also bank reserves for the half decadal period where Mars is not in a launch window. On that station lots of plant growth bays with LEDs and Large array of solar panels that can supply electricity, and of course the station needs to be manned. When we get into the reality discussion, we quaintly have to deal with the fact that the kerbals start their program with no known metropolii, in a junk-yard with a sodded launchpad and a compressed aggregate runway, neither of which are capable of supporting an inter-whereever manned rocket, with a budget a millionth that of NASA. There is no reality to a Duna mission when compared to NASA. The grand solution here is to mod KSC, mod parts, create reality by breaking the realities-that-be, since real reality does not suffice, and fake reality does not suffice, therefore any other reality is just as good.

If you use MechJeb then add 174.6 x 2 delta-v to the orbital burn stage and add additional thrust to the launch stage to compensate for the added fuel weight. The launch phase to 36,000 meters is all but identical to an 090 heading (except the 270 heading on the gravity turn). Between 32,000 to 36,000 meters lower the pitch more heading west bound, otherwise the prograde angle at 36,000 meters will be higher than the trip heading eastbound and the gravity turn will be delayed and the orbit more eccentric than planned. Note that some elevation in apoapsis at 36,000 may be desired, because at 36,000 meters your omega-squared radius will likely be lower, this means effective gravitational force will be higher during the early part of the orbital burn. Because of this one might want to add more thrust to carry the weight and compensate for the loss of delta-v, and you will want to max that thrust during the 32,000 to 36,000 turn west burn.

I agree, rockets are very difficult to control. Its not the aerodynamics, it appears to be timing between keyboard and the stability control unit of the pod. The problem is more noticible if you increase your screen resolution. Apparently as program demands increase the keyboard commands are read as different length intervals and stability control decrease. I had to change my screen resolution because 0.90 flattened everything in the resolution that I was previously using. This meant more video demand and thus more clock cycles to update. Ironically, The longer and heavier the ship was the easier it was to control. One issue you might investigate, SAS does not work without a titled Pilot (see astronaut complex for new astronaut classifications). Basically before any flight you need to select your nauts from the crew tab in the VAB. Pilots appear to get more skilled as they progress. Another issue I found annoying is that KSC eats grounded nauts in physics warp mode. In the previous version it only killed craft above physics warp 2X now it eats kerbals also. Also, parts have disappeared. I can no longer find the air scoops for side mounting air intakes. Other gripes. Basic upgrades for KSC facilities are too expensive, how expensive can it be to have a launch pad that holds more than 18tons when the current launch pad is made of unleveled compressed aggregate. - - - Updated - - - Toggle off the torque unit before leaving the craft. Make sure there are no obstructions close to the pod door or the naut will apply thrust to your rocket as he is kicked off.

OK, so the images where stripped and the vBulletin was placed instead. 32 bit version

Before Launch After Launch: This is what happens after launch Stats Elev = 0 Velocity = 0 Situation Indicator is either Surface or Orbit The bright orange is the bottom of the capsule, therefore the perspective would be up The bar is the nacelle arm. The gratey thing are the remains of the nacelle, only part of the nacelle head mesh remains. To the back is the attachment point of the nacelle. The other two arms and nacelle are missing.

I am trying to build a lander with diagonally mounted nacell arms. There are a ton of problems. 1. Surface mounting parts want to mount at their center, not at the surface of the part. 2. So I fixed this problem by using stand outs, but getting the standouts to form fit results in next-parts that want to mount on the surface mounting side, not on the exterior surface. If I fatten the standout then I can get the next part (a cylinder-modified MK1structural fuselage) to mount on the distal surface of the standout. I have found that I have to get a standout fat enough such that the center to surface distance clearly is exterior to the surface of the radial hub, otherwise the assembler gets confuses and tries to mount the next part on the inward point surface of the standout. 3. Then I get a rocket that looks (in theory with some tinkering) like what I want, but........ 4. Launching the rocket results in launch funk. This is the alter ego of the kraken. Instead you are viewing kerbin from orbit, hitting M centers you on sol, and you cannot revert. The situation indicator reads 'orbit'. 5. On return to VAB most of the rocket is missing, the 3 fold axis of symmetry is reduced to 1, all other parts mounted on the radial 'hub' after the standout are missing, all parts on nacell after the nacell header are missing 6. If I remove the cylinder acting as the branch, all hell breaks loose. The nacell head remains, the screen freezes, I can only exit, and when I return there are no parts on the screen. 7. I have tried tinkering with all sorts of things, I placed side nodes on the radial hub but it wont allow symmetry even if symmetry is set. I have tinkered with the attach rules, the position of the attachment node coordinates, etc. No avail, it seems that KSP has a glass ceiling for doing certain assemblies.

I think it would be nice to have a simple wheel at level 4. You dont need to start with wheels, lots of free career sci in the two launch 'biomes'. Technically you should not seek to build a KSC cart until you have the materials science, Mat Sci and goo are half the KSC sci value (excluding grav sci. and atm). If you want to play by the rules, note that two to four capsules stacked and turned sideways role with a bit of trickery. I took the simplist wheel, rescaled it and use half-factor wheel and modular girder segment to build a car that has at its center a capsule module. The biggest problem surveying KSC is electrical power, not wheels. I modded a fuel fired generator stackable to burn monoprop and then used the 10U on the capsule. What you want is to put some sort of cylinder over each of 4 wheels because some of the KSC targets will not deliver unique (site specific) sci unless you push right up against them, or for kerbins, stand on top of them. In R&D the site specific sci is usually found on driveways that abutt buildings and doorways with large overhangs. Also you need an antenna and to make use of crew reports you will need a pant-load of electrical power.

1.5 g is wasteful coming off the pad (only one third of the rockets thrust is being applied to acceleration), one is wasting E = Mass*4.5m/s*T until one reaches a slower terminal velocity. Ideally acceleration is at structural limit and comes down to 2.0 by the time g-force = drag force (~100 m/s for .2 CoD, and then increases again slowly after 2400 alt. I use SepratronI on horizontally mounted TT38 and scale-mod of RT-10 to make sure my launches get quickly to term, you can always take down liquid engines until boosters are expended. The RT-10 mods can be scaled in size and duration (without exploiting) in order to keep thrust. Alternatively, one can stagger their firing and because they are only used for a minute, they can be batteried on a single decoupler. Most of the weight of a rocket is shed during the first minute of flight, inefficiencies in early flight are the most costly in terms of fuel and success. There is a plateau for pre-orbital ascent, g-forces between 2.7 and 3.0 can add efficiency but not by much, over 3.0 efficiency declines. In addition one has to look at the ISP. For example the Main-sail is very powerful but has a low ISP, plowing this thing into space is not wise, however it is more efficient than a booster. Switiching to an Aerospike over 15,000 feet takes advantage of power (If you can find a way to mount the rocket into a stack). Sheding low ISP weight in low atmosphere and switching to high ISP after making gravity turn (with some speed boosts) gets one into orbit best. There is also an advantage in slower launches to traveling 090 to about 25 m/s horizontal velocity before reaching gravity turn.

You can blow up a fuel tank with an inflated tire. However the VAB took and defected kerbodyne engine on an orange-64 about 4 times before exploding. Too answer the question. some buildings need to be stronger, and others need to be weakened.

Download a xenon harvestor mod, convert hv into fuel, solve two problems at once.

I've seen some of the live streams on Hard Career so I know that folks are having some difficulty with this mode. For me however, I find it rather easy to get started because of all the new little 'Eggs' hiding around KSC. But there within lies the problem. Here are the problems: 1. EVAers getting stuck in the environment, and then being killed on game reload. This is not a new problem, its happened before, the game appears to know when a kerbal has become trapped in its collision mesh and then either makes it disappear, however in career mode, they die. Solution. Hack gravity and try to use EVA suit to extract to a safe place. However this may be having unintended consequences in the game. 2. The collision mesh of some structures in KSC needs to be reworked. Fuel tanks in particular are problematic; for example, on one of the fuel tanks the EVAer was more than a quarter of a meter from the ladder he was climbing, this is where they tend to get stuck. I was trying to get 'Kit' Science from around another tank, not even close to the tanks themselves (meter away) and no heat source, they exploded. However I launched a Big-Orange 64 tank on wheels (with a factor 3 thruster) at the VAB and it took 4 or 5 tries to destroy it, the best hits occurred on the corner of the building. Solution: Is the collision mesh tied to the same reference frame as the scenary mesh? Is it just me or do the two meshes differ on the time-reference from each other and cause temporal changes in how kerbols can interact with the mesh. Maybe the wind is blowing them. 3. Freaky stuff. My first orbital mission in latest career, using standard parts went fine until I hit orbit (36K alt), then Kerbol orbital velocity magnitude immediately became the Kerbol radial velocity vector, the two vectors essentially switched. My ship was suddenly in a near perfect (e=1) eccentric orbit toward Jool's orbit with a subterranean Kerbol (not Kerbin, but Kerbol, the star) periapsis. Radial velocity was ~15,500. In the game I tried to hack and unhack gravity but debug was unavailable. I finally aborted and returned but to no avail. Despite all of this the "Escape Atmosphere" reward was not given, but the Orbit Kerbin was, lol. Solution. On game return I Hacked Infinite fuel and correct orbit before ships travels too far from planet. I think the problem here is that if one has to use hack gravity to release a trapped kerbal, shut down the hack, alt-F12 and exit the game and restart before continuing missions. 4. Funky ground vessels. Particularly in Physics warp, wheel vehicles will collapse immediately, the faster the warp the more apparent effect of 'gravity'. Sitting vehicles literally collapse, moving vehicles explode (immediately) even on flat terrain. Solution: No physics warp > 2 while moving vehicle, but works OK on walking and recharging. This means that the parking brake needs to be set on all vehicles during long walk EVAs. 5. Sub-sites in KSC appear to disappear and reappear. The KSC exploitable regions are not completely static. There are occassions where I sampled a site, returned to resample it and the same site is part of a different domain. (e.g. [sorry don't mean to spoil] the VAB main assembly building become VAB) but if I move to the roof or a different site I can resample. The best example I can give is I had established a kerbal on the statute's domain in front of the statue, came back and found the domain in back of the statue. Solution: make sure to explore KSC objects to see if where-when in space-time they are exploitable, the first attempt(s) may simply be a random failure. I think Heisenberg's uncertainty principle may apply on a much greater scale in KSC. 6. This is not a bug, but . . . . those stairways are nauseating. Trying to keep orientation of Kerbal and keep orientation forward, maybe not the best time to try out physics warp. Hint: for those working ground environment in KSC. The best sites are those close to paved entrances (such as drive ways). Fuel towers might be access by find corners underneath to slip into.