Doc

Launched a giant Duna mission in one go; Launch stage was 7x Mammoths & 12 of the big SRBs. All graphics at max, except for water. Was a little chunky, but honestly not terrible - no worse than KSP1 would have been with my old setup. On launch it was *very* susceptible RUD if you did anything, including zoom in / zoom out really fast, almost like the physics calcs were stuttering and taking too long to finish, so the next 'frame' would start before the prior had resolved. Hard to explain it. IF I left things alone, till it gained some altitude it got much less likely to explode. Not very steerable; felt like the main engines had no gimbal control; even with big reaction wheels and RCS it was iffy. Felt like it needs verniers maybe, something I *never* used in KSP1 After SRB separation, framerate was good. My orbit was really inclined due to the poor steerability SAS felt useless to me. On the whole, though - I had a lot of fun; saved game and will plan on doing the Duna burn tonight

My eldest has been doing the tutorials, since she is old enough to learn. They are well done and useful - she really likes them and it makes the whole learning curve for non-engineers a whole lot nicer

I'm alot less gloomy after I pulled the trigger on a long awaited graphics card upgrade. My initial card was below the min specs, and it would run if I dropped everything to minimal resolution/graphics. The physics ran ok, but was just too hard to see what I was doing. The new card is a bit below the recommended specs, but not alot. With the new card; I really like the look of the game & the sound design is really enjoyable as well. There are some definite 'wow, that's nice' moments. I was able to launch a fairly complex rocket, and excluding a small stutter at ignition, any lag while in atmosphere was not noticeable. There are alot of very nice QoL features that I am bumping in to (like in the VAB, the little cube that shows if you are looking at the 'front' or 'side' of the rocket) all over the place. Construction is just different enough that my muscle memory betrays me; I think it will be better, but have to keep playing for sure.

No, its that the more information you require to get started, the less likely you are to actually start. FAR is great. I don't really like planes that much anyways, so FARs effect on my play wasn't so huge. But. FAR is not easy. Its hard. Especially if you are coming in to the game cold. So if you are going to to implement something like FAR as stock, you really need to think about how you are going to provide the 'right' information so that you can build a flyable craft without doing part of an Aerospace engineering degree. If you are using FAR to design airplanes in KSP and discussing on the forum, you are probably in the top 1% of craft designers who have the game. What is stone cold *easy* for you is borderline impossible for alot of people who love and play the game. The ideal game still challenges you, but is accessible to new, young, or inexperienced players. There is probably a happy medium between what you want (full FAR) and stock what mechanics. As a rule, I think the devs should be going for a model where if it looks 'about right' and obeys a few very simple rules, the craft will be flyable without too much work. I have no problem with a 'well designed' craft flying better, but a 10yr olds first plane should be flyable. What they need to avoid is obvious inconsistencies, like boosters (because of the way their drag is handled) being magic stabilizers, and other things like that. Rather that focusing on the most realistic aero model, I hope they're working on the most consistent model.

And lets go a *tiny* bit further - programming an auto-land routine accurately via kOS is something that is going to beyond a *significant* chunk of the player base. So then we're down to actually 1 option

What constitutes the value of a company? Their Intellectual Property, Their market position (brand) Their people Their management, Star Theory doesn't have much IP; maybe Planetary Annihilation - no value in acquiring them for that Star Theory doesn't have a strong market position; noone is searching for 'Star theory games' - no value in acquiring them for their brand Star Theory had *good* people - enough to get handed an expensive IP by Take Two, and enough to offer to hire en masse when the wheels came off Star Theory doesn't have great management; the company was left high and dry after they failed to deliver on schedule their *only* billable project. That's a management failure What that points me at is that the owners had an out of whack view of what *they* contributed to the operation. Apparently their employees felt the same way.

That seems rather clever, and a good way to handle the issue of resource-raiding OPS - you can't load stuff from OPS unless they have flagged it as 'available' and put some sort of price on it. Would also provide a neat dynamic to encourage building of multiplayer stations, with extra capacity etc. Also, finally a reason to figure out how to extract resources cost effectively. I can see some people getting totally in to designing & operating an out-system giant mining ship...

Seems like there is a half-option in there, where things 'owned' by other people are 'on rails' in terms of your ability to manipulate them. An easy way to deal with this would be to load Other Peoples Ships (OPS) as a single unified object. You can dock with them, etc, but you can't change their orbit / orientation etc unless that's been somehow flagged by the owner. Can use this with timewarping as well; if someone is 'in the future' any craft they have interacted with gets locked onto rails until that point. That'd actually open up some pretty neat opportunities for you to interact with your own ships

Speak for yourself. Star Theory had been given an extension. Star Theory was in negotiations for a buyout, that fell apart. So they failed to deliver on schedule, and then they were asking for to much $$$ in a buyout. Their creative team jumped ship immediately, so they were most likely offered better options than they could get elsewhere. The two guys pointedly who *didn't* get brought along? The two owners of Star Theory. I've been around alot of startups and indie devs. I don't know for sure, but it feels like the owners at Star Theory pushed things too far, and didn't realize just how ruthless big business can be. It ain't puppies and roses. If you take an *expensive* IP, delay delivery, and then start yanking their chain during negotiations? At some point they decide f*** it, we don't need the problem children. When you are out of compliance on your only contract, and you get a buyout offer, you better damned well have another offer in hand before you reject it. That 'buyout offer' translates to 'you guys are screwing this us, here's some cash to hit the road, we're taking over'. At the end of the day, the one thing a large soulless corporate behemoth has going for it is that it tends to make mostly rational decisions - if the cost calculus is good, it acts. If it bad, it doesn't. Star Theory's owners wanted more than their studio was actually worth. Then end. They had *no* negotiating leverage. They have no other solid income stream. They had no other games in the pipe. The only thing they had were their people, and those people were *very* willing to jump ship. TTI could probably offer the entire team a raise and better options by just cutting the two owners of Star Theory out of the pie completely. If you want to be a small company and work with the big boys, you (as management & owners) had better be something really special. So much that the big boy doesn't just decide to push you out.

I would really like the ability to build subassemblies that could be 'compressed' into a single part (from a physics & payload perspective) For example, I like the aesthetic of many of the ball monoprop tanks around a boat tailed (narrowing) tank with a small bell engine. I loathe refilling 8 or 12 of those things manually. It'd be great if I could make an boat tail (tapered fuel tank), 12 monoprop balls, and an engine and then 'force' it into a single part, with the summed attributes of all of them, and the 'net' physics / drag model.

Just a tiny bit of comparison. Your cost - per - hour for each game is thus. Kerbal: 0.375 pence per hour of play Rimworld: 1.580 pence per hour of play Warband: 1.500 pence per hour of play Rome: 2.470 pence per hour of play You have spent (vis your posted numbers) roughly 7,000 hours playing these 4 games in the last ~8 years. I'll assume that you work full time @ a minimum wage job 6.70 / hour (not that you do, but mere for context). That's roughly 13,000 hours worked. Ok, so every two hours you work, you are getting 1 hour of gaming enjoyment. For the two hours you spend working (and earning 13.40 while you are at it) here is the number of seconds you spent paying for each game. Kerbal: 1 second Rimworld: 4 seconds Warband: 4 seconds Rome: 7 seconds Bro, you need to seriously readjust your valuation of your own time. You are quite literally spending less than 1/1000th of your labor on what appears to be your primary form of entertainment.

Gravity assists is a good point that is solidly in the 'plus' column, along with lagrange points. I can imagine 'casual+' players making use of those things. Wouldn't automated stationkeeping effectively be placing non-piloted craft 'on rails' anyways? I am not going to make an official comment either way - since doing things 'the easy way' can often prevent you from doing other things 'the easy way' and then you need to make a complex system over there instead. N-body is neat, but the implementation needs to be handled in such a way that a 9 year old can effectively build a ship and reach orbit, without failing for complex reasons.

That would probably be 'easiest' - just treat everyone elses ships like they are 'on rails' - that'd even solve the time-warp issue. But I wouldn't really call it multiplayer...

That's my bad - I think I was aiming at a different open thread and dumped it here. Because I herp the derp. Sorry

What does n-body physics add to gameplay for the large majority of players? Lagrange points, weird orbits, lots of complexity? Lagrange points are good, weird orbits are bad. I've done games before, and folks on the forum forget that they represent the most dedicated, tiny sliver of the total player base. If you are on the forum, and actively discussing any of the mechanics in a reasonable degree of accuracy, you know more than 99% of the playerbase. This is something that you really need to consider as a developer - does the feature you are adding make the game more valuable or less valuable - players just want 'the best game evar' ; however they define it. So games have to choose the level & type of gamer they want to be delivering to - KSP hit a great sweet spot in terms of realistic-ish challenge (rocket building and orbital mechanics is hard) without being punishing (tiny planets = easy to get to orbit!). Adding N-body (or any other system) needs to keep that sweet spot, in order to maintain a player base. I don't see Kerbal picking up a ton of players from adding n-body, but I can easily see it turning people off, if it makes it harder to accomplish stuff. So it needs to be handled really, really well. That extends out to opportunity cost as well - how much performance is n-body going to eat, that could be doing something else 'cool' (bigger ships? Better physics?) - and also dev opportunity cost. Conics on rails work 'pretty good' to build a really, really fun game. We have a pretty good idea how they need to work to be balanced, and I suspect that they could implement something similar without a massive dev lift. But N-body is going to have tons of edge cases, that we aren't even aware of being an issue. So - what are the benefits vs what are the costs.

Saw this in an article. Latest March 2020 release, for what it is worth https://www.pcgamer.com/uk/kerbal-space-program-2-release-date-multiplayer-everything-we-know/

My bucket of nickles... MP 'seems' like a fantastic option for Kerbal, but we all have lots of questions on how it would actually play out, especially given the tensions inherent in making the game. The obvious attraction is that multiple players can 'collaborate' on projects which scratch their own particular itch, but also have parts they don't really like. For instance, I love designing and building ships & bases, but once I figure out that they are actually possible to assemble, I get bored. Some folks love the sim aspect of cruising their rover around or their crane and actually putting stuff together. So we can co-op. I deliver cool base modules, they stack them up. We're both happy. Yay. Or you can run in a more 'competitive' mode, where multiple space agencies are vying to be 'the most awesome' - competing on a space race, for colonization, for science etc. The problem comes with the tension in how the game works; to be coop, we need to be able to interact with our fellow players constructions. To have the power to interact in kerbal is to have the power to destroy. If the power to destroy exists, there are going to be griefers. It is known. In all cases, we have some real problems with synchronization due to the 'time warp' nature of the game. We *need* time warp to accomplish any of the goals in the game - even a mun mission is nuts if you try to do it in real time. So time warp is a given. That right there is, I think, the essential problem with MP. How do we allow for people to conduct missions according to 'their own' schedule, without ruining other peoples planning. I honestly don't have any idea how to make this work well in anything outside of a very friendly group of players. But lets just assume that they come up with an elegant and effective way to keep everyone in sync. That still leaves the issue of ship interaction <-> ship destruction being a huge risk for bad player behavior / griefing. Even in a small group of friendlies, the massive frustration that everyone would experience if Bob got drunk, and accidentially mistimed his retro burn when approaching our 2 year old station, would be *brutal* One thought I have been having alot recently is the idea that solving bad player interaction could be countered by putting a ship/station/base 'on rails' - so that its configuration, orbit, etc was converted into a semi-static object, which you can't affect via physics. Things like docking ports etc could still be 'active' to allow for interaction, but it would be more like as if the VAB had a docking port bolted to it. This would allow players, via some sort of process to put some things 'into statis' and beyond the ability of other players to interfere with. It could be done in alot of ways, but simply having 'ownership' of a ship and then a toggle to put it 'on rails' or not would be easy. Likewise, a 'merge ship' option could be easily implemented, so that once you dock to a ship on rails, you can vote to have your ship 'merge' with the railship, and then the railship owner accepts the request, and poof, your module is now 'bolted' to the on-rails unit. I think that there would need to be a two-step process for putting anything on rails - for instance, anyone in the local physics bubble has to agree, or the server has to majority vote agree, or the server owner needs to agree. The 'ship on rails' thing is also a possibility for handling different ships owned by other people. It would be possible to treat *every* ship, not owned by you, as 'on rails' and indestructible. That would be a big lever to prevent griefing, especially in competitive games it might be sufficient to just run it that way 100% This would introduce some weirdness, especially w.r.t. docking; if you just 'bounce' off I think something like the above system I describe is how the devs would need to handle a thing like the colonies they are describing, or the orbital VAB structures. Being able to de-orbit the super VAB, or break it, or whatever would be neat for a few people, but super annoying for the great masses. .

I am just going to throw this out there - not saying it is or is not what happened. But alot of smallish companies (like squad) need to set milestones, which they need to achieve, by a certain time, or else they can lose control / money / flexibility - the banks, VC guys, and run-of-the-mill partners want to see a certain progression. It is completely possible that '1.0 before May 1' was a milestone that made 'unpleasant' things for the company happen. Is 1.0 perfect - not really. Is it a big step forward? Oh yes, yes it is....

So I've started on this challenge a half dozen times, but get distracted (constantly). Here is my mission that actually should -actually- finish. Mods: DRE FAR KW Rocketry Mechjeb TAC Life Infernal Robotics I use standard reusable lifter that puts ~38 tons to LKO with each flight, and an 8 kerbal crew lifter. All missions comply with the ... <to be continuted>

I stick my 'thrust around heatshield' engines out on Infernal Robotics telescoping pistons. I extend them to thrust, then retract for re-entry. Works pretty good.

Hey Claw, I haven't tried this fix yet, but it sounds like it's a bang up for what went wrong with my station. Thank you for all your hard work in trying to run this down. -Doc

Getting ready to launch a full TAC-life Duna exploration mission. 6 crew, round trip, with manned landings. I'm using a variant of my munar lander with a shielded descent stage, but the rest of the lander is *not* that aerodynamic, but its still duna, so I hope FAR doesn't kill me. Also building a LKO OKS station, that eats up all my extra income

1.100.000 for testing an Aerospike around minimus. Icing on the cake is a LV-1R test for 300.000 *also* around minimus. 1.400.000 for a <50k launch... Which is a good thing, since my giant OKS LKO gateway station & Duna explorer mission have really been sucking up funds.

I really like the new difficulty settings buuuuuut I loathe it when a rocket freaks out, for no reason known to man (or kerbal) Like when a rocket just disintegrates on the pad, because some sort of clipping problem. Or when I somehow fire 4 stages at once (1 spacebar -> 4 stages?) So... I've started playing with no quicksave and revert is OK, since most of the 'wtf' errors happen there...