paul23

It's easiersaid than done for "single core cpu clock". Since different architectures can do vastly different things during one such cycle.

Well I currently am running an MSI gp 60 laptop (with some added ram to make it 32 gb). However I notice that KSP is slow as snail on this setup, really not running well and playing terrible at times, even simply modded instals with just a 100ish rocket parts drain framerates to abysmal levels like 5-10 frames per second. So much that I often give up on larger missions like eve space stations. (With USI life support to be fully self sustained). I've now looked into buying a normal pc and am looking for advice regarding the video card/processor (and motherboard) to buy. Can anyone give me suggestions? For cpu, I am thinking between: amd ryzen 5 5600x/ AMD Ryzen 7 5800X / intel i5-10600k / intel i7-10700k For GPU: the gtx 1660S or (high end) rtx 2060. I also wish to have at least 64 GB of ram, though those price are much lower. In total I wish to pay around 1200, max 1500 euros for the total build, so the GPU + CPU should be below 1000 euros. What I mainly use my pc for will be kerbal space program, and (modded) minecraft. As well as for programming (hence the requirement for at least 64 GB ram).

I consider mechjeb also vital nowadays. The boring idea of constantly burning at right the correct time is just annoying, similarly after you've made 20+ transfers it's just a matter of inserting those - and then mechjeb just solves that.

Having a lifting surface means that the center of lift moves further back due to an object. The more lift a tailfin generates the further it moves back. One would always want the center of lift behind the center of mass.

How are the delta wing better, when they have so little actual control surface area?

Well those two winglets seem to fit the same purpose, both adding control at the bottom of a rocket-stack. However the av-r8 winglet seems clearly superior: much larger control surface (full winglet instead of a tiny fraction). Only weighing a fraction more (and often in the first-to-throw) stage so it won't matter. Is there any reason I would pick delta-deluxe winglet over the av-r8? Other than looks which cannot be discussed.

I tried that mod.. However it still has a similar problem: I still need to scroll (in a very small window) through the 20-30 parts that hold crew to find that single crew I need to return to kerbin for a medical emergency contract. This mod shows which compartments have crew, but not the other way around: showing where specific crew is in the station.

Someone needs to calculate this into the correct warp number.

Healthy distance from star is actually not a good thing to have. Being close is often preferable for a space faring society: any such society should have fixed the "propulsion" system down to energy. And close to a start means much more readily available energy. (Until we start going dyson sphere).. But more importantly: close to a star means many more times a transfer window. Where a far planet would take several years, and another far planet would also take those, to get the correct alignment would easily take 10+ years at distance dres-jool. Yet with something close like moho it happens multiple times a year.

Well as per title, I often have stations with 10+ the same hithchiker or a few science labs. And it becomes a real pain trying to find the location where a kerbal is sitting, to move it to another location. This is especially impossible with modules that have to air-lock and thus I can't quickly eva just to notice their location. So is there a mod that can help me? Either (preferably) a mod that allows me to "move" kerbals without selecting the cabin they're in, rather by using the protrait. Or otherwise a mod that (in the protraits) gives me a hint at which kerbal is where.

The merging ship satellite has no open nodes itself.

Well I have small drones/satellites that should be added to a big hangar-like generation ship used to travel between kerbin and the final destination of choice. In the vab, while editing the big ship, I tried to add the small satellites. However they wouldn't attach to decouplers (surface attach). Even the root node won't. How would I handle this where I have drones and wish to add (say) 12 to a mothership?

I was happily landing head first into the ground, so should be safe. When I suddenly accidentally rotate the kerbin making it land on its lags and going 'poof' when traveling nearly 100 meter/second.

Well as per title I came back to my old save and wish to update the game. However I notice that the modlist I use has most mods "stuck" at version 1.8.(9). Which means I wish to play that version. However I can't seem to find any download for version 1.8.x anymore? The websites only lists 1.9 and 1.10... And older than 1.4.

There is hardly any reason not not go oxygen-hydrogen unless you take many more complex situations into account. (like being able to store the liquid, on earth). Hydrazine would never ever be used if it didn't need to be used, it has worse chemical efficiency per mass is highly toxic and hard to handle. Then there's the corrosiveness and hence the choice of metals that depend on the fuel. Or how do you model the toxic disadvantages for the environment in a fuel? If this is then reduced to "you can have fuel xyz with engine abc, and other fuel with other engine", where each engine can have a single fuel. Then what's the difference in just abstracting it away under thrust and specific impulse? I suggest you'll first read the book "Ignition!" by John D Clark. It shows the choice of liquid fuel.

The altitude difference between mountains and flat area is really minimal in regards for landing: if you crash on mountains you'll crash on sea level too. Mountains just make you tumble over easier.

shielded ports also greatly reduce lag, when the shield is closed they act as if they are disabled.

You mean in real life?

I hade a lander fully landed in water once, then before recovering I went back to base for some reason. When I reloaded the craft, it apparently started "sinking into the water" and went through too high speed submerging, making the tank and consequent lander above it go "poof".

Hey I wonder if I can ask a question about syntax here? - can I "repeat" a part of the configuration "for each element in a list", or in other words: use an iterator inside a behaviour node? Currently I have a (working) solution that is like: BEHAVIOUR { type = ChangeKerbalType onState = CONTRACT_COMPLETED KERBAL_INFO { kerbal = @/candidates.ElementAt(0) trait = @/candidate_traits.Random() kerbalType = Crew } KERBAL_INFO { kerbal = @/candidates.ElementAt(1) trait = @/candidate_traits.Random() kerbalType = Crew } KERBAL_INFO { kerbal = @/candidates.ElementAt(2) trait = @/candidate_traits.Random() kerbalType = Crew } } With candidates and candidate_traits being lists. This sets at completion the trait of candidates to a random trait. However I wish to update this to not explicitly call `ElementAt(x)` and instead reuse the whole `KERBAL_INFO` part for each candidate inside the candidates. Something like: BEHAVIOUR { type = ChangeKerbalType onState = CONTRACT_COMPLETED for (candidate in @/candidates) KERBAL_INFO { ITERATOR { type = Kerbal kerbal = @/candidates } trait = @/candidate_traits.Random() kerbalType = Crew } } However that doesn't seem to work, when I do above the following error occurs (in alt-f10 menu): [ERROR] ContractConfigurator.ChangeKerbalTypeFactory: CONTRACT_TYPE 'Tourism_SpaceCamp', BEHAVIOUR '' of type 'ChangeKerbalType: Missing required value 'kerbal' so how to iterate in behaviour nodes?

Actually greenhouse gasses keep a planet warm, without those earth (and other planets) would be frozen over: so it's perfectly normal, just like the average temperature on the moon is also around -70 degrees.

Hmm I wonder: is there a converter to allow me to enable editing like it's stackexchange/github? To convert markdown to forum posts, and also vice versa? Especially the editing is abysmal.

I have a real aversion to things like wormholes and warp drives: mainly because it removes a core function from the game: the orbital mechanics. When you travel faster than light gravity can no longer be an influential factor. As such the whole idea of "orbits" is removed from the game, and you can almost travel in a straight line. Even if relativity is not taken into account. "near future" things like orion engine, or vasimir and solar sails (infinite specific impulse for a solar sail) would be perfectly fine with me: they have theoretical roots and do not violate physical laws.

My biggest gripe, apart from what mods like far/kopernicus fix, is the fact that ksp considers kerbal a perfect sphere. Being an oblated sphere adds a lot of fun to the mix, from having to do station keeping, so actually using it to change argument of periapsis "for free".

Where did I do that? I am not talking about the trajectory at all, I'm just outlining a baseline for calculations. You are the one making a statement, so the burden of proof falls upon you. Again I'm not talking about a straight line. Though I'm considering a simple trajectory where you always fire prograde, but instead of lowering thrust to make a "gravity turn" you turn just like doing a hohman transfer. Indeed I am. However as the vacuum specific impulse is not that much higher than the sea level impulse. Combined with the fact that the more simple proposal, of just firing much more straight/with full thrust, and "firing again during apoapsis", means a larger proportion is fired in vacuum. Not at all, I'm not talking about thrust to weight ratio. The gravity loss I do consider to be equal, since the distance traveled (70km) is small compared to the total radii (600 and 670 km). Again not at all, where do you get his impression? What we need is something that can easily be repeated by anyone. Something that can be verified, a craft with instructions how to fly. Either a video talk about the control input and design or something else. So long as anyone can repeat your results. I'll test out the design later once I got time away from the family. This I get a chuckle with "fuzzy math". If there's one field you simply cannot be fuzzy in it's math. I come back to my earlier statement which is that the burden of proof lies with the claimer, the "simple" formulas show otherwise. As for why you see such low thrust to weight ratios in real life applications: this is due to (a) payload restrictions, and (b) it's hard to make rockets with more thrust, and more thrust means often much less thermal efficiency. No what I propose is just firing enough power to get a short burn to get the apoapsis up, the direction I am not even talking about, I'm just talking about doing a very short burn. Doing a short burn will mean you will fly "straight" as you call it for the latter part/coasting to the end of the atmosphere. After which you complete the circulation near the apoapsis. I am advocating always burning at full thrust, or at least after reaching a minimum altitude, and not lowering thrust to "keep doing a gravity turn". The direction I have not made any statements about.