Waterlimon

MM free gamies gib for me yes... Excited for explosions.

How does the full network look thru tracking station? Maybe they have some hacky SOI hierarchy based approximation for general connectivity in case someone feels the need to sprinkle 10,000 relays across the system (they need the full network viewable in tracking station with no lag?). So if they go moon->planet->sun->other planet as an approximation, it would give the path you get. Would expect them to override with precise calculations for transmission tho. I wouldnt be surprised if the path depends on active vessel from simple numerical errors, because of the distances involved.

You can still add KSP to your steam library, so you can run it through steam (google how if you cant figure it out), but it wont be an actual steam game. People online said it would get steam overlay this way, but that didnt work for me (I wanted the steam FPS counter... squad plz implement natively)

Procedural generation would not work because: Its easier to create content by hand when its getting as slowly as it is in KSP, especially since players sharing the same environment is nothing but good. The actual problem is that youre stuck at KSC. That is what makes the game repetitive. This wont change no matter how much you mess with the outer planets (which the average player will never fully explore anyways, I assume) The best way to add content is to: Add detail through procedural generation (not scale, not new planets) Manually add a few hundred additional planets and moons. Theres room. At most requires some minor UI improvements. And then fix the real problem and give the player 10 unique space centers spread across the system in completely different conditions/environments, that players get access to when they 'conquer' that celestial body in some way (commnet access, having station there, managing to land there, maybe buying it, whatever). Maybe throw a space center in space for end-game. Thats how you fix the repetitiveness. Promising content in the form of a whole new randomly generated system doesnt help much if half the players get bored while exploring the first one for a few hundred hours.

Map of every relevant situation where kerbals can be permanently stationed. Shows number of kerbals there. Include goals. Station N kerbals in X situation => Get reward. Could be contracts, but I feel its better to let the player decide what order to do things (stationbuilding contracts already exist anyways). Award reputation for stationed kerbals (could be a bonus based on amount of currently stationed kerbals, so it goes away when the kerbals do). For harder difficulties, if a stationed kerbal doesnt have commnet access, incur high temporary reputation penalty (goes away when access to internets fixed for the poor kerbals). High because its a rare circumstance and guaranteed to go away when you deal with the issue, which shouldnt be too difficult. Could be hundreds of rep. Add new tourist+ / citizen type kerbal, fixed cost or free (or even give you funds), who you can fill your stations (and the system) with. Unlike the current ones which just get more expensive. Limited EVA would be nice (maybe no jetpack, or less fuel). Update stationbuilding contracts to require them be actually filled with these kerbals. Add larger, more specific, systemfilling goals as contracts, such as "have this many kerbals living on every moon of that planet". Basically contracts that dictate the order in which you should fill the system, maybe with deadline, instead of you doing it in whatever order/timeline you feel like. Add contracts to move the kerbal citizens from one station to another, since now you are guaranteed that kerbals will actually be present on stations instead of them all being empty. Now, this would make stations feel less 'forced'. I feel like something like this (just tracking kerbals across the system and tying that to some rewards), is the minimal solution, and kind of necessary (unless a more complicated solution is preferred). Later on, it would be nice if reaching a certain kerbal population somewhere would let you do something like set up a small space center there (like a fixed location per planet, where you can build a mini-KSC if you have enough kerbals, fuel, electricity on that planet) Contracts could prefer bodies where you already have many kerbals, to a certain point, so every playthrough naturally gets a different set of focus points. Assuming the player plays along (people can always go against the flow, send kerbals elsewhere, and force the contract systems biases to shift)

They just dig a hole and dump the craft in there. Why bother bringing vessels back to KSC, when they can find new parts so easily all over the place with nothing but a metal detector and a shovel?

The only remaining option is to use kerbin to alter your trajectory (without landing), bounce around the system a little more, and hope the second intercept is both possible and slow enough.

In KSP saves folder, theres 5 (by default) autosave backups. That might be far enough to take you back to an earlier point. I dont know how to actually access them since theres no ingame way to load autosave backups (I assume you just replace some main save file or move the backup to the regular saves folder - but dont do anything without looking up exactly how, and even then backup the folder before trying anything)

Can you do some aerobreaking passes to form a less energetic orbit around kerbin before finally landing? If even that is too fast (ie cant slow down enough to actually stay in kerbin system after first pass thru atmo), then idk. Maybe pull some crazy maneuvres using the moons?

A giant balloon/airship-based launch / drop test facility. There should be multiple such facilities. They would either just drop things from launch clamps (like an inverted launchpad). Or they would have a runway. Or both. Uses: Test parachutes and other parts of landers by dropping them from high. Get to places with gliders, not requiring any fuel at all. You cant glide if you start at sea level. Make kerbin-based contracts actually fun, when you dont have to fly 10 hours to get to the other side of the planet. You can just drop a glider or a lander with a rover from a nearby airship (not TOO near, has to be balanced). You can still use planes or rockets, but more options seems fun here to keep things nonrepetitive Launch spaceplanes and specialized rockets above dense atmosphere (with drawbacks, ofc) Allow more interesting contracts for planes (transport things to/from airships) Allow challenging attempts to land on one from orbit (destructible like the buildings on land). Act as relay or point of reference for ground based things Ideally balloons and such would be added as player-usable parts at the same time. The facilities could be built using those, if some mobile launch pad stuff is added as well. The facility does not generate fuels. It has finite storage for that stuff. Refill must be done by player. Refill contracts are possible. Refill is not necessary for drop tests or gliders, since those do not need fuel. Perhaps monopropellant could be generated by the facility on its own (assuming its just nitrogen from the air or smth). Lack of fuel generation would be the main drawback. For practical reasons, mass/size limits might exist as well, but I feel like those just make things less fun. There COULD be some mass based launch cost (presumably the parts have to be shipped up there somehow), to balance things against ground facilities.

Could you keep ksp pre-loading these terrain chunks by switching through an array of pre-positioned ground stations parallel to the race track, ahead of the speeder?

My theory is that once upon a time there was everything and there is still everything because time is a human construct, and one of the things is the universe, and we are in the universe instead of some insanely complicated thing BECAUSE the universe is one of the most efficient structures that can give rise to life COMPARED to its complexity (sure complexity EMERGES from the universe, but the fundamental rules that it follows are much simpler), so there are more of "universe" contained in "everything" than there are "overcomplicated thing where potatoes spontaneously spawn everywhere".

Ah yes, your quadtree coding idea is easy to do (at a high level, dont know about implementation): 1. Take picture 2. Interpret as bits 3. Split in half in some way (so theres two sets of bits) 4. Interpret the halves as big integer x,y coordinates. 5. This is unique location of image in that rectangle of yours. The sequence of choices to find the image is trivially computable from the integer x,y coordinates. (first step is given by first bit of x and y coords, second step given by second bit, and so on) I assume you want the images to get "closer and closer" as you go deeper. Not sure how to do this, but I would begin by optimally choosing how to order the bits of the image when interpreting it as x,y integer coords. (you want the most significant bits to have most effect on the image - perhaps the image should be encoded as fourier transform, or maybe something like gray code where one bit at a time it goes toward the target, idk)

Lua was written with the goal of maximal simplicity and being easy to embed as scripting language IIRC If you use LuaJIT its very fast too. Though its mainly a scripting language, not used as often for standalone executables. And I would say a more strict language with strict typing leads to better code and more things learned.

Just make it a QR code that links to the wikipedia page on humankind

Sorry if it looks flat I... turned my graphics down because... performance, yeah...

All parts have some drag, and the only two things affecting the drag are: -Parts directly connected to it using nodes (radial attachment doesnt count) -Full containment (cargo bays, fairings, and other built in containers) So when determining the drag a part creates, you can ignore all other parts except ones directly connected through nodes, and containers. (as far as I know) For the connected parts, it probably just ignores drag for the surfaces covered by attached parts, so when you add a nosecone, what you are doing is trying to completely remove drag from the surface you attach it to (and assume the nosecone itself has less drag, resulting in net win) I dont know specifics when it comes to partial coverage - maybe the game knows the exact area of all attachment surfaces and calculates drag from the noncovered area, or maybe it just applies full drag, or maybe it has some nonsensical system that has nothing to do reality and just happens to give somewhat correct results...

No, I hadnt done anything to the machine for years, and then suddenly the old HDD (still with power) started clicking :/ (so I just unplugged it, which I should have done when it died... I probably had just unplugged the data cable only)

So, many years ago, my secondary HDD broke (it was an old one from previous computer, supported with blu tack because it wouldnt fit so I couldnt use the proper screws...) All was fine for all those years, but today, I heard constant 'click click click' if the computer was on. First I was afraid my main (and only in use) HDD was going to die. Took me a while to figure out that the old HDD still had power connected to it, so I just pulled the wire from it and now all is fine... Wonder what triggered it to come back to life...

"20:02" "2O:O2" "2O -> O²" Something oxygen something chemistry something confirmed!!111

Fill the cargo bay with parachutes and wire the abort button to drop an engine or two when pressed.

I see your home planet has about 512 air.

My suggestion: Instead of rendering only 1 line from 1 point of view, render a whole stack of lines, from slightly different points of view. Like human vision, except with 1000 eyes in a row instead of only 2. This would allow for depth perception. If the objects are infinitely far, all the lines are equal (changing point of view has no effect) If you are looking at a bullet right in front of your face, the middle lines (assuming lines are horizontal and center of screen is the 'middle eye') would show the bullet in the middle, and smallest of all lines (since the bullet is long so if you look at it from front its smallest you can get). The farther left or right (top/bottom of screen) you go, the longer the bullet gets (not significantly) AND the farther from center line of screen it gets (for leftmost 'eye', bullet would be on right side of screen because its close) This would result in each visible object forming a thick 'column' from top to bottom of screen, except its not straight. Distant objects are straight columns. Nearby objects change thickness depending on line and are a bit skewed (amount of skew determines distance from viewer)

I wouldnt say all the hours are equally valuable so the comparison is not valid. I would place the hours in a continuum between 'new content' and 'wasting time' (not in the negative sense) What I mean is, that if I were to use 10 hours to get my craft somewhere, there might be 2 hours of 'content' (new situations, making decisions) and 8 hours of waiting for stuff to happen, performing some really slow transfer manoeuvre, or going back in time to redo something because you failed (if I do 90% of a missin correctly and fail, Id have to do that exact same 90% again with only the last 10% being new content). If we consider the AAA titles, often its a steady stream of new content. With KSP, youll be doing the same things many times. With KSP, there is a stream of new content as well, but it slows down with time and is a bit slow to begin with anyways. A more valid comparison would take your KSP hours, multiply by lets say 0.75 (to account for the gameplay being generally slower paced instead of 1 GB of assets per minute being thrown at your face), and for all hours above 50 multiply by 0.25 (because youll be spending so much time doing the same things over and over again and generally things taking longer etc where during first hours you have all these new parts and planets and such to play with). so 1000 h -> 750 h -> ~200 h ??? Its like even if you have a movie you like to watch again every year, you dont really get as much out of it anymore so you wouldnt want to pay the full price every time (unless you only pay based on how much time was wasted). So comparing 1000 h in KSP to 1000 h of story in some 500$ AAA+++ game doesnt really work, since its not only the time, its also the quality of that time (of course you might like KSP more than anything and give a 0x multiplier to hours of entertainment on all other games, which is probably what you did when you didnt choose to buy those games but bought KSP). I find KSP more than worth the price not because of hours wasted on building rockets, redoing missions or waiting, but because of the few moments where I understood how something works or something interesting happened as well as the entertainment offered by content on the forums which would be difficult to understand without playing the game, but doesnt really count toward playing the game.

Instead of using a better integration (your problem is basically using a bad integrator, check ones like leapfrog algorithm or RK4 or whatever) technique (which is an approximation, like eulers method assumes velocity is constant over a frame, when its not, and better methods assume the velocity changes linearly or is given by a polynomial or other such approximations), you could do what KSP does for orbits and describe them explicitly. What this means is that you actually calculate the orbital parameters (eccentricity, inclination, whatnot, i dont know, google for relevant material) and save that as the orbit. This means you can calculate the exact position of the orbiting body based on time, with no drifting whatsoever (since you saved the exact orbit instead of it just forming as a result of inaccurate physics approximations) Of course you need to update this saved orbit data when nongravity forces act on the craft, which means it wont really work if theres a constant force like a thruster thats constantly on acting on the craft. Use explicit orbits if the orbits remain unchanged for long periods of time, thus avoiding numerical accuracy errors.