Kelvin Kerbin

Just FYI, the 1.3.20 build of procedural parts doesn't seem to function right at all with this (see following mod list from CKAN) RO-RP build. The part has no special menu buttons and doesn't seem "procedural" at all. It may be that the mod works and is just not attached to the same item in the part list (not sure if that makes sense) but when I click on what used to be the "procedural tank" or "procedural battery" in the part list all I get is a plain jane part with no ability to resize or anything. { "kind": "metapackage", "abstract": "A list of modules installed on the KSP 1.7.3 RP KSP instance", "name": "installed-KSP 1.7.3 RP", "license": "unknown", "version": "2020.01.09.02.43.55", "identifier": "installed-KSP 1.7.3 RP", "spec_version": "v1.6", "recommends": [ { "name": "RealismOverhaul" }, { "name": "RealSolarSystem" }, { "name": "FerramAerospaceResearchContinued" }, { "name": "RSSTextures4096" }, { "name": "AdvancedJetEngine" }, { "name": "SolverEngines" }, { "name": "ModuleManager" }, { "name": "KerbalJointReinforcementContinued" }, { "name": "RealChute" }, { "name": "RealFuels" }, { "name": "CommunityResourcePack" }, { "name": "RealHeat" }, { "name": "ModularFlightIntegrator" }, { "name": "RealPlume" }, { "name": "SmokeScreen-RO" }, { "name": "Kopernicus" }, { "name": "CustomBarnKit-RO" }, { "name": "RP-0" }, { "name": "ToolbarController" }, { "name": "VenStockRevamp-NewParts" }, { "name": "SXTContinued" }, { "name": "FirespitterCore" }, { "name": "FirespitterResourcesConfig" }, { "name": "RetractableLiftingSurface" }, { "name": "ContractConfigurator" }, { "name": "DeadlyReentry" }, { "name": "VenStockRevamp" }, { "name": "VenStockRevamp-Core" }, { "name": "KerbalConstructionTime-173" }, { "name": "MagiCore" }, { "name": "ClickThroughBlocker" }, { "name": "DMagicOrbitalScience" }, { "name": "DMagicScienceAnimate" }, { "name": "B9-PWings-Fork" }, { "name": "EnvironmentalVisualEnhancements" }, { "name": "InternalRCS" }, { "name": "JanitorsCloset" }, { "name": "KerbalAlarmClock" }, { "name": "Kerbalism" }, { "name": "Kerbalism-Config-RO" }, { "name": "kOS" }, { "name": "KRASH" }, { "name": "KSCSwitcher" }, { "name": "MechJeb2" }, { "name": "PersistentRotation" }, { "name": "PlanetShine-Config-Default" }, { "name": "ProceduralFairings" }, { "name": "ProceduralFairings-ForEverything" }, { "name": "ProceduralParts" }, { "name": "ROCapsules" }, { "name": "ROEngines" }, { "name": "ROTanks" }, { "name": "RSSDateTimeFormatter" }, { "name": "SCANsat" }, { "name": "SemiSaturatableRW" }, { "name": "VensStylePPTextures" }, { "name": "PlanetShine" }, { "name": "TexturesUnlimited" }, { "name": "BDAnimationModules" }, { "name": "B9PartSwitch" }, { "name": "PatchManager" }, { "name": "Scatterer" }, { "name": "Scatterer-sunflare" }, { "name": "Scatterer-config" }, { "name": "Toolbar" }, { "name": "PADContinued" } ] }

Are you sure about that? I think pressing caps lock cuts the output thrust such that the RCS induced rotation is controllable by the SAS. Have you used RCS with caps lock on and SAS off to see if you rotate?

If you wanted to implement a label like function but do so using windows folder structure you could simply store all craft in a special folder you don't display and then place windows file links to the craft files in the windows folder structure. You would then have the same craft in multiple folders but have only one physical craft file for that ship.

If I have a ship with a probe core and the electricity runs to zero (when the planet the ship is on rotates and it is "night"). When the electricity goes above zero (when the planet rotates and it is "day", it has solar panels) the ship comes back to life but the SAS doesn't work. The probe core will not hold the ship steady, nor if it's an advanced core will it show the buttons to hold the prograde/retrograde/normal/etc... directions. I have the following Mods installed: Kerbal Engineer Hyeredit Kerbal Alarm Clock Is there a way to recover the probe core SAS functionality? Is this by design or is it a bug?

It would be nice if the quicksave feature saved a series of saves instead of just one. So the first time you quicksave it saves as quicksave #1. The next time, quicksave #2 (or quicksave #1 and the previous #1 is renamed #1, etc...), etc... You could have a max of x (user defined, dev defined) quicksaves and delete the x oldest one. Pressing reload quicksave would still reload the last quicksave. What is the point of this suggestion? Many times players do not realize how corrupted (unstable) a save is until after they have made it. It would be nice to go back to older more stable saves without having to specifically name each one with the Named Save feature. The devs might also have access to better troubleshooting information.

They look really good, have you flown them? Have you landed them?

My math shows that it should take ~18dV to change orbits from 20km to 10km. I checked it in KSP too and that seems about right. This dV map (and several others): http://i.imgur.com/iqmlAfm.png shows 3070dV to 20km. That would imply around 3050 to 10km. Quick math shows it takes a dV of about 200m/s to reach 10km in Tylo's gravity and it takes around 2030 dV to orbit Tylo at 10km so an orbital dV of 2070 is really close to an idealized engine (infinite TWR). I think the dV map you used is ideal and from a practical perspective it takes a lot more than 2070 dV to reach a 10km orbit? I see that it will take your ship around 60s to expend it's 3 km/s dV. That is not ideal so it takes your ship 60s to fight gravity over the ideal scenario and with a gravity of 7.8m/s^2 that would be 468 m/s additional dV (at least). Since the first stage has the worst TWR the losses fighting gravity are probably a lot worse and then you probably didn't do everything perfectly. Just use the Hyperedit mod and then you won't loose your Kerbal.

I'm curious, why don't you wait until the launch site is on the satellite orbit plane and then launch directly into that plane (as opposed to launching into the equatorial plane and then changing orbital planes)? I've always launched directly into the satellite orbital plane and found there is a slight dV cost (over launching into an equatorial plane) but it didn't seem anywhere near the dV cost of actually making a plane change, especially for polar orbits. Then again, it just made sense so I've not run a proper scientific test of the idea.

I'm having a problem with the BZ-52 part overheating. Per unattributed suggestions (sorry to forgotten person) I modified the part to increase thermal conductivity: @PART[stackPoint1]:AFTER[squad] { heatConductivity = 0.95 // default is probably 0.12 } but the problem continues. I turned on the thermal data and noticed something strange. One BZ-52 usually "fails" after warping and four are attached to a "Rockomax X200-16 Fuel Tank". I noticed this tank had a Cond Flux of several thousand (about 8K IIRC and dropping rapidly) shortly after one of the failures. I did not notice any unusual temperatures (all around 200-300) but one (of four) BZ-52's had already failed due to overheating (temp >2K). That seemed odd, especially since you would expect that after warping all temperatures would have reached equilibrium or that each BZ-52 would have heated roughly at the same rate. Before warping there had been a short burn with a Skipper engine and the temperatures had appeared to be in equilibrium after the burn. I'm wondering if some attempt is made after a warp to all at once equalize temperatures starting in some sort of pattern and that is somehow leveraging a weakness in the BZ-52/temperature interaction? I realize other people have temperature problems with the BZ-52 and just do not use them. I am curious if anyone else that is having trouble with the BZ-52 has seen the same thing or may know of other solutions to the problem. Also, how is heat conductivity modeled in the game? Heat conductivity should be the rate that heat moves through a material. But each part is only modeled with a uniform heat. In other words, the heat on one side always equals the heat on the other (infinity thermal conductivity). So what exactly does the game use "heat conductivity" for? Does a low heat conductivity make a part heat up faster, cool faster, both, neither, how does it interact with the heat conductivity of surrounding parts, etc... Does the game use the attached surface area to model heat transfer between parts and is there something about the BZ-52 part model that is impeding this? If a part has a Cond Flux of 5K does that mean that the Cond Flux from all attached parts has to equal -5K (not assuming flux into or out of these parts too)? Why would I see a large Cond Flux without a corresponding large temperature change? The mechanics are all very fuzzy so thank you to anyone who can clarify some of it. :-) KSP 1.0.4 Color Coded Cans Fuel Tanks Plus HyperEdit KAS Kerbal Engineer KIS Modular Rocket Systems Lite Nav Ball Docking Alignment Indicator TAC Life Support Transfer Window Planner Universal Storage

Being proud of reaching 300 pages before release so you can have a nice story having grandchildren pretty sure you can have one or the other but not both...

Enough for what? What would making equal numbers of male and female Kerbals accomplish? Funny, if we are really talking about equality, maybe some females making videos about KSP would help?

The Round8 Toroidal Fuel Tank was repurposed as a 1.25m inline Xenon Tank. I like the tank as LF/O but I can accept that the people who own the game get the final decision (no whining). I do think that it's polite if you want to be heard to consolidate your feedback. A simple poll should help the devs (if they are interested) in canvasing the user feedback without having to paw through a 20+ page thread. I hope that if this is not helpful it's at least not impolite.

SpaceX Dragon can put 1lb in orbit for $10,000. A barbie weighs 7.25 oz. So, about $4,500 if you can convince Elon Musk to put it on his rocket. If he can land the booster then he claims he can cut costs by 100 so that theoretically brings the cost down to $45. The claim for the future is $10/lb which works out to $4.50 for the barbie. Of course, barbie is pretty thin and Jeb is sort of chunky but he looks shorter than barbie so maybe it's a wash?

KSP is about a lot more than just orbital mechanics, it's about design...for launch; orbital maneuvers; planet encounters; space construction; planet construction; etc... Assuming you are talking about a kid who is interested in learning about designing ships for orbital maneuvers, I would caution any kid who feels he is learning to design ships for orbital maneuvers without designing said ships for launch is fooling him/her self. It would be like designing planes to fly but not takeoff or land. Any kid ONLY interested in learning orbital mechanics can do so by running the in game tutorials. Those have ships already in space they can fly around all they want. Luckily, there is a pretty easy solution to gain the limited knowledge outlined. Installing the HyperEdit mod allows you to move a ship directly to orbit and skip the launch. Launch is pretty rote without proper aerodynamics and almost any crazy thing will go up so having a launch stage without aerodynamics is pointless from a "learning" perspective (ignoring the absurdity of learning from a game). IMO, installing mods is much easier than designing things that work so hopefully this suggestion (if spread wide and far) would remove said stumbling block and would be considered a positive response to the proposed problem.

When I click on the link it says I do not have permission to view the page. Anyone have a link to the post on how to disable unconnected network adapters? Thank You

easy "no" because as of now the game isn't even close (by Squad's own standards). Adding a bunch of features and fixing an unspecified list of bugs (some really serious) doesn't inspire confidence that the game will be ready. My statement is a commentary on software development in general and not Squad specifically. No matter how talented the developers at Squad, things like that do not happen. As someone earlier said, bug fixes come last. It's not that you can (or should) only fix bugs at the end, just that you would have to have zero software development experience to not schedule time at the end for bug fixes. That said, we are mostly on the outside looking in. This product was in "alpha" and is now in "beta" but both are superficial designations. For an "alpha" build, KSP has been remarkably stable (too stable IMO). For a first release "beta" build, KSP is remarkably feature poor but with expected (perhaps average) stability. If this were a "real" final beta build I would say the stability is not where it should be. I've experience game killing issues 40+ hours into every game I've played. Why say anything when the game is still in alpha as that is expected in alpha. But in beta I'm having the same problem with no solution and now Squad says they believe it's ready to go? So far, Squad has not shown a product close to feature complete (by their definition and most of those here) nor release stability (by everyone's definition). But there are development cycles internal to Squad as well as external to Squad (but still "inside" the general public release cycle). Any commentary on this board can only be on the clearly "fake" build information available to the board. From that perspective, the answer is "no" but Squad can do this if they change their development model (less back and forth with the customers and more behind closed door development cycles). Personally, that sucks because feeling like part of the development process has been one of the things keeping me interested. If Squad shuts their doors and disappears for 6-12 months to pull this off it will be a pretty disappointing change. Regardless, I'm still a supporter and would say: -- Godspeed Squad.

Game Files, everything that isn't static (ie. with 12/15 build date) from the game folder. (including: game saves; ship files: crash reports; log files; dxdiag computer specifications; etc...) https://drive.google.com/file/d/0B46l7avI4cJvdFFIbWJGUXdPNGM/view?usp=sharing KSP Version: v0.90.0.705 Beta Windows 7 64-bit What Happens: Game looses core functionality shortly after this save before next persistent save occurs. (see below) Mods / Add-Ons: All Stock (no MechJeb, no FAR, nothing) Steps to Replicate: 1) Use "Kerwin Kerbal" persistent game save. 2) There is a craft titled "Space Shuttle", take control of that craft. 3) Rendezvous with craft titled "2 Crew Lander w/ Rover" (it will take several orbits, about 5 min tops). 4) EVA Jeb to Lander. 5) Reverse orbit of Lander (yes, the Lander is going the "wrong" way). 6) Game will become unplayable before this point or shortly thereafter. The game starts to stutter before getting to the point that it no longer playable. I've tried removing all the extraneous craft flying around (including debris) and the game still locks up. The game doesn't hard lock, it just get's to a point where you can't change ships; return to the Space Center or even save the game. Before getting to that failure point, things like Jeb automatically piloting to the radial, prograde, normal, etc... points stops working. It's like the code breaks down and gracefully looses functionality. The game might superficially appear to be working correctly but then you notice something you need to do just isn't possible and you try to save and you can't save, etc... This big seems to happen whenever I get "far" into the game. When I have several stations around planets and ships on missions things just fall apart. This "bug" has occurred in numerous games (ie. restarts from scratch) for the last year but this is the first build that was fun enough to play this far without mods. The game really is looking fantastic, couldn't be happier with the vision. I didn't think it was "fair" to hand a problem like this to the devs with a modded game but the core degradation seems consistent and with this build clearly tracks to the game core itself. When you get "far enough" into the game (superficially I correlate this with a certain number of missions/ships in space but it could be a time thing or another factor entirely) everything seems to fall apart.

As the title says, when Squad announced that the 0.25 update is "in experimentals" does that mean it is in the final stage of testing? Is it like an alpha or beta or a term internal to Squad or just KSP? I only ask because I was curious what the Squad post meant? Thanks!

I don't know if this will clarify anything or not but "RocketFuel" = LiquidFuel (aka "JetFuel") + Oxidizer. My guess is that when you select "RocketFuel" in the heavy converter you will get both LiquidFuel and Oxidizer (plus XenonGas). It's what the screen in the VAB says will happen. There's a limited space on the selection screen for the converters so I'm guessing those descriptions are brief for that reason. FYI - You can move the liquidFuel from a "RocketFuel" tank into a "JetFuel" tank and the plane engines will work on it. They are the same in the game.