cerberusti

If you still wanted an eve ascent vehicle, this is the one from my recent career (I built and flew it last night). It has generous margins, a full science package, three crew, can land and take off from land or water, moves decently fast in the lower atmosphere to get from point to point, and is relatively cheap and small at 230k credits and 218 parts. https://steamcommunity.com/sharedfiles/filedetails/?id=2604415070 I decided to play through again as this is the last patch, so I deleted all my old saved games which mostly no longer work well and made a "Final" game. I am mostly only doing the progression missions and general science, and doing each progression mission as presented. Eve is the first planet, and after the flyby I had the mission to return a craft from the surface. Minmus and the Eve flyby (with as science lab) provided enough science to entirely run the tech tree prior to this mission, and after buying facilities I had a couple million to build the return craft and a general use tug to get it there. The progression mission itself is: Splash down into the oceans of Eve Walk on the surface of Eve Return to Kerbin from the surface of Eve Another goal was to hit each biome if possible to get a nice full science load to return for reputation and cash, and I also had a contract for one volcanic rock, so it needed to be able to move a bit. There are a few options here, from multiple minimal drops, to suborbital hops with an ISRU, to a separate ascent vehicle and plane they can use to run around the globe then return, to spaceplanes in both the SSTO and staged variety. I went with a staged spaceplane, mostly due to the visit to each biome taking a while and saving inside the atmosphere not being ideal (so you do not want to screw up a landing). SSTOs are marginal enough that you cannot really carry niceties easily, such as science, extra crew members, safety margins, etc., and going large to compensate for the mass is kraken bait under Eve conditions. I prefer a small craft which does not cause any additional lag. Not being a masochist, I designed it in the mission builder first. There are no mods installed and nothing clips, it is entirely stock. It works with all settings, including g forces (nothing will be destroyed or crash, although everyone will pass out during Eve entry with plenty of time to recover before landing.) Only fill three crew, one of which should be a pilot. It will initially make orbit from Kerbin by flying to 5km or so on propellers (action 1 to start and stop propellers, action 2 opens and closes the cargo bays, custom slider 1 is propeller angle, hit F12 to see the aero display to make takeoff easier, and pin a rotor and a propeller to see useful metrics), then close bays and use the attached boosters from there, staging them when empty, and expending most of the fuel on the craft to reach orbit. It is marginal without the boosters, and may be able to SSTO itself on Kerbin using just the one vector plus a full fuel load. I wanted an easy ascent without redesigning anything so I just strapped on a couple of small boosters to get it off Kerbin into orbit intact. Press action hotkey 2 to close the bays, and 3 in order to disable fuel crossfeed on the top decoupler once in orbit, so later during the ascent it will not move on automatically to the last stage of fuel. I did not need this fuel during my ascent from Kerbin, but if you do you can use it. The standard docking port on the top is aligned with the center of mass once fueled, so your space tug of choice can dock, refuel it, and push or pull it to Eve. It should be in an Eve orbit between 100km and 200km when detached. Once in a suitable low Eve orbit, turn retrograde and open a fuel tank menu on the outer wing structure then carefully use all the the fuel in the wing structure to get down to a safe entry speed. It has twice the DV for this purpose than I managed to do this with in testing, and that makes it a fair bit easier and more reliable to survive reentry. Do not use the fuel in the ascent vehicle, which you need to manually watch and stop as while fuel priority uses what is should first, it will not cut you off automatically before using the ascent fuel, as it is using the engine for the ascent vehicle to deorbit. I vaguely turned towards the horizon and up side up before hitting the atmosphere, but I am not sure how necessary that is. The spin on entry may be destructive without it as the g load will increase rapidly. Cut sas once entry effects show up and let natural aerodynamics take over. It will orient itself so it is against the wind and slowing at nearly max speed (CoA is above CoM), so it will lose speed very quickly. Nothing should overheat although it will show the bar, and if the g forces setting is on everyone will pass out from this. It will fall until about 20k, where it will naturally start reorienting towards prograde, by 15k it will mostly be stable and you could start flying if desired. Letting it fall to 1km or so then turning on sas and landing is faster. Once on the surface or in the ocean, stage the fairing off of the science package. Fly around doing science, the container at the tip can store it for ascent easily and it can go decently fast. If you need to use the ladder on land, the gear should be raised to lower the ladder into reach. All experiments which need to be cleared between uses are in range from the ladder. When ready to ascend transfer the kerbal into the cabin, make sure any science is collected, and stage the science package off. You can ascend at a 70 degree angle at over 100m/s on propellers, until you reach about 16km, at which point you should stage the wings off and max out the engine, keeping the 70 degree up heading until the vector runs out of fuel (which it will if you hit 3 earlier to disable crossfeed). Stage the vector off to enable the terrier and aim for the horizon, there is plenty of time to ap to make the burn. Once in orbit undock the docking port to leave just the cabin, command pod, and docking port, which can be dragged back to Kerbin, attached to a landing pod, and dropped into the atmosphere to return the craft.

It is also worth a mention that a quick trip or two to minmus where you biome hop is a good way to max the tech tree out.

That was from sea level to orbit (I think I actually launched it from the ocean). The ship itself is a little bit old, but the numbers it gives in the mechjeb panel for TWR and DV at both sea level and vaccum should be near what you want for stages. You need a lot of DV, and you need a ton if you lack the engines to punch through that super dense atmosphere quickly. You also need to pay attention to aerodynamics, as it matters quite a bit. I do not have a screenshot of the landing cage, but that was less... good. I had a large heat shield in front, and two more in the back providing drag so it faced the correct direction.

You need the vectors, mammoth, aerospike, or propellers with electric motors to do this without an unreasonable amount of pain. Most engines simply lack the ISP to be at all reasonable in terms of fuel or thrust at that atmospheric density, and there is a great deal of gravity to fight. You can try wings, but you need an engine with the highest sea level isp possible. You can also try the top of a mountain. This was my last sea level eve ascent (for three kerbals and a science package), although it is a few patches old at this point: I suppose nothing but mainsails could be an interesting challenge.

It depends what you mean by working. I have a test craft that can take off vertically under rotor power: https://steamuserimages-a.akamaihd.net/ugc/800991879186028145/BD40FDBDC1A784563C2D9FD8988B574538A9A3EF/ https://steamuserimages-a.akamaihd.net/ugc/800991879186028579/F4508A401CF7B7D1CDE01FAFF18E81EC0298B7E6/ transition to forward flight: https://steamuserimages-a.akamaihd.net/ugc/800991879186028936/C1192EA32ABF8204E3803CBB6A638540A516A9BB/ get up to about 70 m/s still on rotor power only: https://steamuserimages-a.akamaihd.net/ugc/800991879186029237/A2A44813643BE5CA245C8028D79431B7D07E835C/ and fly on jet engines with the blades feathered and off: https://steamuserimages-a.akamaihd.net/ugc/800991879186029531/380493D634BFC8741FA4D937D4DFB9554C769A4F/ Hotkey groups set the rotor angle between 0, 15, and 60 degrees, switch hinge orientation, and power the engines. It has more than enough RTGs in those bays to fly forever, and even to add extra rotors (this is a test bed). It is very stable and difficult to destroy, unless you feather the blades fully with the motor power on. I also have a plane which can lift a mammoth and a couple of suitably sized tanks into the air by the end off the runway on propeller power. I have not managed to get it to fly long without disassembling itself, and even taking off is a 10% of the time affair. That does make use of multiple stacked rotors from both directions, but you cannot get much above 500 rpm. If you stack 2 on top of each other on some batteries, it sums to just over 500, but that is also true if you stack 5, or if you stack 4 with two rotating from the other side. It very briefly exceeds 600 total, then seems to limit itself to around 500 for the entire stack no matter how large. Once you hit the limit one of the rotors will also start wobbling quite a bit. You can stack rotors (either opposed with opposite motor rotation or on top of one another) to increase speed so long as it is still under the limit. You can exceed the power the motors used to set rotor pitch can handle with a stack and large blades, in which case you need bigger ones. I decided it needed to be smaller for stability.

The shielded docking port makes a superior spaceplane nosecone when you plan to hit high speeds in the atmosphere, although you will need a bit more engine to push it supersonic (I usually dive a bit). I have been using no spring and maximum dampening on my gear recently, it seems to help with the insane wobbly bounce. If putting gear on wings it helps to not only use the rotation as described above to make sure they are straight, but to angle the entire craft upwards a little bit so the back gear makes contact first and you avoid dropping the heavy rear of the plane hard enough to tear the wings off. How far can we take the detachable part? Can I move the payload from low orbit out to 300k with a detachable tug and dock again before landing?

I named mine "JoolBus", and had landings on minmus, bop, pol, and laythe (my JoolBus is a spaceplane). It has an ISRU, but I usually do not need to refuel given that it has nukes and the entire trip usually only uses 4 - 7k vaccum dv (out of a bit over 9k in lko). You pretty much just need to get there, gravity assists make almost everything cheap if you set it up right (a maneuver node editor is highly recommended).

I did recently notice how superior the shielded docking port is as a nosecone. I noticed this on somewhat large planes (200 - 500 tons), I do not know how well it works with small ones. It lets you fly a better (and more forgiving) ascent to get more out of the jets, which seems to let me get more to orbit than I can with less drag and more heat worries. Not needing to worry about riding the line with heat as much, and the convenience of a docking port at the front also help its case.

Setting it to anything high enough that the precision is no longer enough to store the amount of time elapsed since the last check of the system timer is going to lead to the unfortunate situation where new_time = current_time + frame_elapsed_time; will result in the values of new_time and current_time being identical. This means the timer never moves, as it cannot add a small enough amount to it to advance the clock by the amount it wants. This is what cantab was talking about when they noted that you will have problems as the precision you can store approaches the frame rate. In reality there are also a bunch of other things which could break or cause strange issues as the precision drops.

If it is stored as a count of seconds in a double, the last point at which it is accurate to a single second is only 2^53. Problems are very likely to start well before this point, although the exact point at which it ceases to be accurate enough to continue running will depend upon the specifics of their program.

It is unusual to place this many fuel cells on a craft, which reduces the importance of the issue. It is probably as simple as they never tested it with so many, and are using an algorithm which is not efficient as the number of parts grows. The way to fix that (if they are interested in doing so) is to change the algorithm to something that scales better, not to split it off to another thread. A more efficient algorithm may be far faster, it is not unusual to see speedups of hundreds or thousands of times when fixing an inefficient algorithm (for that calculation at least.) The best case for the physics calculations is still going to require a lot of computation.

I would set it back. There are some windows api calls which fail if you have the page file off, and it disables a few windows features. Windows is decent at choosing what to keep in memory, even if it sometimes evicts program data to cache file data.

This is intended to be informative rather than argumentative, so please take it that way. While I may have given a program from my current employment as an example (it makes a particularly good one), I am generalizing from a couple of decades of experience writing high performance code for everything from mainframes to industrial machinery. While I may not know the specifics of the KSP code base, unity, or write games for a living... I can make an educated guess as to what causes the issue, and have some idea as to what to expect in terms of scaling to multiple threads. Server workloads which involve multiple concurrent requests are usually what we call "embarrassingly parallel". Each client is making a request which does not rely upon the results of other pending requests, which means scaling to multiple cores, processors, or servers tends to be easy and work well (and is a big part of the reason server processors frequently have many cores.) In the case of scripting languages (for say a web server) adding more threads also tends not to have the same negative performance impact due to cache pressure, as programs in languages higher level than C++ cannot be easily optimized to force efficient cache and memory use anyway. At the opposite end of the spectrum are tasks where each calculation relies upon the immediately preceding calculation, and branches are unpredictable. For these tasks not only do they not scale at all to multiple threads, they will struggle to even use the multiple execution units within a single core (which do not require threading to use, it happens automatically.) The physics calculations are somewhere in between, but will be much closer to the latter than the former (that analysis does not require looking at source code, we can determine this based upon what the problem is.) Maybe they could put the solar and aero calculations on their own threads, but even something like that which at first glance looks like it could easily be parallel may not be. When on the same thread they can load the part and do all of the calculations at that time, which has the benefit that the part information all of those calculations must reference will already be in the L1 cache, or maybe even in a register. If these are not on the same thread that information may not be in the cache at all, which means loading it from memory instead (which additionally evicts something else which may have been useful in a future calculation from the cache to make room.) A quick googling for a chart to show just how serious a cache miss or lock acquisition can be for performance gave the following (these are rough numbers as hardware differs, but give a general idea as to what costs are.) Mutex lock / unlock in the table is what you need to do in order to safely access data from more than one thread (and also the part many programmers totally screw up or leave out, leading to race conditions and other nasty threading bugs which cause intermittent and hard to trace problems.) L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 100 ns Main memory reference 100 ns Compress 1K bytes with Zippy 10,000 ns Send 2K bytes over 1 Gbps network 20,000 ns Read 1 MB sequentially from memory 250,000 ns Round trip within same datacenter 500,000 ns Disk seek 10,000,000 ns Read 1 MB sequentially from network 10,000,000 ns Read 1 MB sequentially from disk 30,000,000 ns Send packet CA->Netherlands->CA 150,000,000 ns At an average IPC of 8.5 for a single core and a clock speed of 4ghz, a single cache miss costs around 3,400 instructions. A lock and unlock on memory which needs to be accessed from more than one thread costs around 6,800 instructions (double that to 13,600 for two threads which need to do it), which is part of the reason a task needs to be highly parallel before it is worth trying to multithread it. The mutex numbers actually seem a little high to me, so that table may give a worst case. KSP may gain a little bit from multithreading, but it is not likely to gain much in the scenario people mostly see an issue with (launching a single large rocket.) I do not get the impression they have spent a ton of time optimizing KSP, so there is probably some low hanging fruit they could go after rather than trying a difficult and error prone solution which will only help under specific circumstances.

That last line is all kinds of wrong. There is nothing easy about writing a correct multithreaded program, KSP is very likely to be sensitive to memory latency (probably not bandwidth), and the performance increase from implementing multiple threads is likely to be minor (although we could disagree on the meaning of "significant".) Which calculations do you think will see a large benefit from this? If you are thinking the physics calculations I doubt it would benefit much (and this is the source of most performance issues in KSP.) It would probably work out ok on a rocket with multiple stacks which share only a single connection point, but those tend not to fly. Place some struts and the physics for that stack now relies upon the others, which means you are waiting on the result even with multiple threads. The overhead to make sure the result you need has been calculated and the related memory is not being updated can easily be more than you gain by multithreading (or you ignore that part and end up with a buggy program.) There probably is some performance to gain by multithreading KSP, but there are probably also much better ways they could spend the time they are willing to dedicate to improving performance.

That would work, it only cares that you satisfied the requirements at the time. Once you have done that you can do whatever you want, I have used the same craft to fill a few base contracts and a few ore contracts.

I have a 4790k (4ghz, 4.4 turbo) with some very fast memory, a good video card, and an SSD. I get lag (yellow mission clock) at anywhere between 300 and 1000 parts, depending upon what those parts are. Aero parts, solar panels, and especially struts cause a lot more lag than simple rocket parts. Strut placement can change performance greatly, as it impacts which parts the physics calculations must take into account (a web of struts links everything to everything and will crater performance even on my very good computer). I am also a programmer who works on optimization of programs which process large data sets, so I have some insight as to what the possible bottlenecks actually are. I see a lot of complaints that games are not optimized well simply because they do not use all of the cores on the processor, but this is almost always due to a lack of understanding on the part of the user as to how a modern computer works and what the limitations are. The extra cores are there in case they are needed, they are not full processors. The only reason you have 4 cores is that it takes very little die space to do that compared to extra cache memory, but the vast majority of the time they are expected to be idle, even if your processor is maxed out. The thing about the multiple cores your processor has is that they all share cache and memory, and very few programs are actually limited by the number of calculations your CPU can do. It is *far* more common for a task to be limited by either the amount of data which can be transferred from memory, or the latency of those requests (which can sometimes be hidden by clever programming tricks.) Multithreading a program which is limited by memory almost always gives you worse performance, and removes the ability to use certain very important optimizations (those threads compete for the same resources, and knowing what a thread is up to in relation to other threads requires very expensive synchronization commands.) I actually produce a program which has a multithreaded version which is not something we just distribute. You can get it by contacting support, but they have been instructed to ask if the computer it will run on is multi-processor, or multi-core. It works well if you truly have multiple processors, but running the multithread version on a single processor which has multiple cores results in much worse performance as the threads compete for cache space and memory transfer (8x - 50x slower.) You may think it should not be worse regardless when the task is split across two threads, but a cache miss leads to an extra transfer from memory. If you have two similar tasks competing for cache space and memory access, the extra cache misses make extra memory requests, which delay all other memory requests. This leads to a far worse than linear performance degradation. In my case, very intense complaints by a specific important client who was annoyed that it did not use "all of their processor" led to a version of the program which maxes out all cores. It does this by querying the processor for how many cores it has, and starting up enough threads to fill it. The trick is that only one thread processes relevant information, the rest add 1 to a register in an infinite loop (which took a little effort, as the compiler really wanted to optimize it out). This results in about a 5% speedup overall, as it prevents other programs from running well (I also set the priority pretty high, so it stops almost anything else from getting CPU time). Be careful of what you wish for. KSP may or may not benefit from multithreading, but the assumption that is it poor optimization is not necessarily correct.

The actual highest point is up a small hill from the coordinates given, so it is only close (I used them to make some attempts at a more useful ssto which carries real gear and an ISRU.)

1) I way overbuild my craft, I frequently land back on kerbin with 8k or more DV once I have nukes (before that I am extremely frugal, but as cost pressure relaxes I get very lazy.) 2) I name craft "x station" and drop kerbals onto a planet permanently with a load of science equipment. 3) I am considering a hyperedit on my no cheat save, as I did not realize I could not time warp with a kerbal on a ladder. This is a rescue of both a low Jool orbit and a low Tylo orbit, but I did it with one pod, and it needs to make a rendezvous. I could drop a kerbal and refuel at a depot before going back, but I am too lazy to do it. 4) The only non atmo landings I can pull off are a suicide burn (which I am very good at after realism overhaul and needing to do it with a single ignition and little to no throttling.) 5) I dock by aligning ports and using main engines, I am terrible with RCS... I almost never bother even including it. 6) I sometimes build whackjobian monstrosities and use them, I have a craft named "JoolBus" which can SSTO to a landing on any body and return (except eve)... with 100 kerbals and all equipment. The thing is kraken bait though, it frequently destroys itself just sitting in orbit even without sas on (I end up tapping time warp frequently to settle it before it destroys itself if it starts shaking.) Incidentally this is where the craft listed in 3 would need to refuel, which is why I do not want to do it.

Sounds like an underflow and wraparound, I assume the pole is supposed to be very cold. If that really is the problem, a workaround may be to ensure you are generating a lot of heat.

There are some good tips above, but to add to that: 1) Minimize drag. This really matters for a space plane since your main challenge is breaking the sound barrier. Every stack should start with a shock cone, and end with an engine. 2) Minimize engines. Atmo engines are dead weight in space, so if you want to go anywhere beyond LKO you want to keep it to a minimum (if you do not need to go beyond LKO it instead increases payload fraction.) 3) Read some guides. Goslash in particular has some good information on appropriate lift and such if you look around. 4) Carry a small amount of lf + O even with a nuke powered plane, a burst from the rapiers on stored oxygen does wonders for getting your AP up. Flight profile is: 1) Best pitch where you are still accelerating until you are at 10k to 12k 2) Level off and get to the point where you are no longer accelerating. 3) If you have not yet broken the sound barrier, dive a little bit to get there (which is what the 12k is for, it lets you break mach 1 while diving slightly.) 4) If you still do not get there, temporarily turn on any extra engines (like nukes) to get a little extra thrust (even RCS if you have it, this is the hard part which you should throw everything you have into.) 5) Start a minor climb once you are rapidly accelerating. 6) Accelerate to at least 1000m/s on air, you want to be closer to 1200m/s if you can manage it. As you near top speed turn on nukes if you have them. 7) Pitch up a bit, when you start slowing down pitch up more and switch to stored oxygen (until it runs out if you have nukes, enough to hit your desired AP if not.) 8) Circularize. Reentry is simple with wings even without airbrakes (I do not use them, and never have problems.) You should be at maximum pitch up, let drag level you out against all forces you can muster (unless you are not suffering heat much and want to reenter faster, which I do in most cases to save time.) Also, to reiterate what was said above as it is super important. NO STRUTS. Do not even think about it until you can easily make an SSTO and are building something very heavy.

If you really have trouble, put a small engine under the docking port. This will let you take weight off the suspension to get to the height you need (especially effective on low gravity worlds, where you can get away with a very small engine for the mass).

Going in engine first from Mun or Minmus works without a heat shield (I would save first and do it through trial and error, the exact pe you need will depend upon your craft.) If you have trouble, skimming the atmosphere a few times will slow you down enough to make it easy (you may need to do this if you have surface attachments with a low heat rating which you are not willing to lose... spinning helps to even the heat out here.) Interplanetary trips are the real concern, as you need to slow down enough for an orbit in one pass. A gravity assist from Mun can help, but not nearly to the degree which something like Tylo will (you can get a Jool orbit with nothing but a gravity assist from Tylo if you make sure you get there at the appropriate point in its orbit.)

I have one with an ISRU which can make minmus (or laythe), so if I am willing to wait for it to fill on the runway (or launch with less than full fuel) I can turn a profit from the trip. A more interesting cheapest to orbit is probably minimum vehicle cost to get a single kerbal up there, without deducting recovered funds.

Master of Orion 2 is one of my all time favorites (it is on GOG, but not steam.) While it was released in 1996, it has held up better than any other game I can think of from that era. On steam Terraria and FTL are worth checking out if you have not already done so. If you were looking for something more recent Satellite Reign was pretty good (although looking at it that was $30, and it was not as good as some of the older cheaper games.) XCOM enemy unknown (and the DLC) are also very good (although also more like $30 before the DLC, or $50 if you buy it with the expansion.)

The rules as they are really encourage maximizing the number of people you land on Tylo. Maybe also have a category for lowest mass to successfully land from and reach 80x80 orbit without staging ranked by either weight or cost?