The Great Potato

: / I'm torn. I like all the features in here, but I also really like Remote Tech! Proper background processing is something I've wanted in RT for a long time. This mod adds it to my relays, but at the cost of...well...everything else in Remote Tech. Time to go rooting through configs, I guess.

The difficulty for mun landing in career is funds and facilities, not max thrust imo. There is far more to mission difficulty in KSP than the max power of your current boosters. Playing career, I don't think I've ever managed to get maneuver nodes before filling out the tech tier where 1.875m would fit most nicely. In fact, I usually already have a handful of 2.5m parts by the time I get nodes (unless I really turn down the science slider). And then I still have to upgrade the VAB before I can make a suitable mun rocket. I also disagree with the sentiment that limiting parts demands creativity. The power gap between sizes 1 and 2 actively teaches the 'MOAR BOOSTERS' dogma to new players - after reaching orbit the first time, contract requirements go up dramatically but you won't get better hardware for another two tech tiers. What are players to do in that situation, other than go hard brute force tactics? Currently, the only kind of problem solving early career mode teaches is how to game the weaknesses within its own simulation. Bridging the gap between sizes 1 and 2 will present more options for rocketry: for the same job, 1.25m is cheaper and lighter but 1.875m is simpler and uses fewer parts. Assuming the existing size 1/2/3 power, weight, and cost ratios hold true for 1.875m, of course. A little more granularity will help players understand and work with size-based engine stats and their tradeoffs, which are a very real engineering concern. Teaching simplified real-world mechanics while encouraging engineering creativity...isn't that what KSP is known for?

@Alshain No mods. Size 3 with a cluster of 5 engines; with 12 struts placed in a truss pattern around the edges, the rocket is slightly more noodle-y than if I used a rhino. Not by much, but enough to give it a noticeable wobble. I didn't really consider unity's physics...KSP itself usually only goes downward, but I imagine physics would constantly be going either direction...okay, you convinced me. I can still hope, though I was gonna bring up the auto-tankbutt on the Vector. I've had my fingers crossed for mounting-less engines since I saw that. Butts won't do anything for the adapters, though...they still need to mount tanks without clipping. How about a stock thrust plate? @Frank_G The stock fairings work great as interstages in a bunch of situations. The main problems are when you want to put a fairing around something with no center node, or when you're packing a payload LEM-style. You have to spend an awful lot of parts so it jettisons properly and doesn't flop around in flight.

I'd say some combination of Vessel ID, part focus, and mission time (adjusted for timewarp, potentially). For vessel switching...perhaps it should bring up the dialog even if you're back in the original vessel. Or maybe switching should reduce the timer on triggering the dialog (from 20 mins MET to 10 mins MET, for instance). There's no way to stop accidental quickloading entirely, but I'd like to error-proof it so losing >30 mins of game time is less likely. At least if you hit F9 and no dialog pops up, you know it's not that far back. You might have to redo a single launch or reentry or landing, but not a whole set of maneuvers or rebuild a craft.

I'm very familiar with the fixes, I do them all the time. And no, the struts are often not quite enough. Even with 10-20 struts between the adapter and the tank, there's a little more flex than if I were to use a skipper or poodle in place of a reliant cluster. A little extra bendiness halfway down the rocket is not optimal, to say the least. 'Spam struts' is always an option, but I don't like it. It's still totally is a hack by my definition, and not because of clipping. Squad specifically disabled radial attachment on engines; those cubic struts are used to circumvent that. But that's splitting hairs - regardless of what I call a hack, I'd prefer a more elegant solution to interstages and clustering. Eh, you're right. It's a very unlikely option, but I wanted to suggest something other than interstage attachment nodes. Squad seems to prefer features that don't involve hanging attachment nodes or fiddly sliders, and I tend to agree. Allowing multiple parents isn't as complicated as you make it sound, though. Squad could stick with the tree model and keep special cases for stack splitters. Or they could change to a graph model, which - assuming the root still can't have a parent - is nearly the same as a tree for downward traversal, subtree removal, and re-rooting. Upward traversal is the real killer, but I can't think of a place where it's used in-game at the moment. Regardless, this requres a change that's deeper than the modding API. Suggesting a mod with this feature would be futile. There are rumors of a v1.2 rocket rework, so recommending such a major change to bi/tri/quad adapters isn't completely out of the question.

Sure, that'd become a habit if the dialogue popped up every time. Not even close to what I'm suggesting. To be clear, I'd want F9 to bring up a confirmation dialog only if it would cause a flight scene change. You know, as a 'stop and think for a second' warning. If anything, the reflex would be to cancel it. I can count on one hand the number of times I've actually needed to load to a different craft. Saving a backup when you quickload might work in some cases. In most others...it would dangle your old data in front of you with no hope of return. Quickloading generally happens when something goes wrong, so returning to that point is often useless. And remember, loading disables the 'revert' button. Better, imo, to figure out a way to prevent the accident in the first place. Back off topic: don't we already have a 'you haven't saved!' dialog for exiting the VAB? I really like the 'go to SPH' idea, though.

Nah, it's fine. There's no real way to make the workaround look pretty. Usually, I use pancakes for the extra fuel and easier fuel line attachment when clipped in. I use this setup a lot, but I have a bunch of problems with it (other than the obvious aesthetic issues): First, Having the decoupler there can cause issues, especially if you move the engines a little further inward. I've had a bunch of launches where the girder/decoupler collides with an engine and goes kablooey. Second, this uses a size 0 to hold up a size 2. You can strut it up, but struts won't give back the rigidity of an actual 2->2 connection. There will always be some degree of flex at that joint. Third, this is a hack. Getting this to work requires a lot of clipping and every part involved is used in a way that's not intended. Most importantly, it completely ignores a series of parts that are actually intended for this purpose - bi/tri/quad adapters. The adapters should be slimmed down so they actually fit under 2.5m tanks. Adapting and un-adapting a stack should also join all the hanging nodes together. In addition, adapters need to be moved waaay down the tech tree (meta-materials? really?). That would at least solve engine clusters. As for payload interstages...I think the fairings could use a toggleable interstage node, but I don't see that happening in stock.

I'm playing stock again for the prerelease. Without utilities like KER, precise node, trajectories, etc I've found myself using quicksave trial and error a lot more. The trial and error is fine with me; I'm more worried about what happens after that flight. Occasionally something goes wrong a mission or two later and I reflexively hammer down on the F9 key without thinking about when I last saved. ...Aaaand boom. I'm in my orbiter from 30 minutes ago instead of in my plane. I think it might be a good idea to add a confirmation dialog to the quickload button if the last save was on a different flight scene. Thoughts?

What about the roles of "lower stage for a size 1 pod" and "payload for a size 2 lifter"? Size 1 is too puny to take even size 1 payloads much further than LKO. However, I don't think they should be buffed - size 1 works well as starting equipment. You start off struggling to even get LKO with them, which is good. Remember when you could get to the mun with 35 science and a handful of funds? I don't want to see that return. In addition, size 2 payloads are often too heavy-duty for the task. Any size 2 payload requires a large-ish and expensive rocket, even if you just want to get more than one Kerbal to orbit and back. Size 2 is the go-to option for a ton of stuff; not because its efficient at those things, but because it is the only choice. As it stands, career mode goes from "struggling to do much more than orbit" to "finished the apollo program" in the space of a single tech tier. The existence of a size 1.5 would filter some of those possibilities down the tech tree.

Kind of a thing. If you try to wrap an interstage around anything with a relatively small diameter, you end up with a really bendy rocket. Modules packed up Apollo LEM style and engine clusters come to mind. You can reinforce the interstage, but it will always be a little noodle-y even with an excessive number of struts. Since I have an obsession with engine clusters, I'd use the living hell out of a stock interstage option. I like the stock fairings better than PFairings - they're way cleaner and less fiddly. It would be nice not to have to install PFairings just to have interstage nodes.

There's a very real need for a size 1.5, especially in career. Aesthetics are a part of this, sure, but you can say the same of any suggestion for parts. Playing stock recently, most of my rockets need something with more power than size 1, but size 2 is complete overkill. Just look at John JACK's math in the second post - that is the best indication of the problem. There's also an uncomfortably large gap in the tech tree between the Reliant and the first Rockomax engine. During that time, the Reliant is it. The most powerful engine in your arsenal can barely lift 15t. Better hope you upgraded the VAB - you're gonna need a lot of parts.

Squad said they're not distributing the pre-release through the patcher because it's not equipped to do so. Steam has built in pre-release functionality and version control, so they went with that. Maybe the launcher is flawed, but would you have preferred Arsonide or RoverDude or somebody work on fixing that instead of one of the new features in 1.1? There's no ill will from Squad - they would if they could but they can't so they don't. 1.1 isn't even all that different from 1.0.5. 1.1 is all about the backbone and UI, not the gameplay. If you don't use mods, 1.1 mostly gets you new wheels and a couple slightly improved visuals (and a healthy number of new bugs). If you do use mods...most of them aren't updated yet so the pre-release will mean nothing to you. I have KSP on steam and my 1.0.5 install is alive and well. I get the initial disappointment - Squad did announce the Steam-only thing a little on the late side. The way people are still so salty about this is strange to me, though. They apologized, it's temporary, it's just the pre-release and not actually 1.1, etc etc.

I use a game controller unless I'm docking or on EVA. Or if I need lots of buttons. Roll is on the bumpers and yaw is on the control stick. That way, I can pilot rockets and aircraft with the same control scheme.

Picked this up again today. After an embarrassing amount of hair-pulling, I found the ScienceSubject and ResearchAndDevelopment classes in the KSP API documentation - they were exactly what I needed! Using GetExperimentSubject and SubmitScienceData, I can convert pretty much whatever I want into both Science and a valid R&D Archives entry. Now I can start building new and more interesting ways to collect science! ...There are still a handful of smaller things I'm unsure about, though. I've been able to work around them, but I'll eventually want to find better solutions: How the heck do you get the vessel's current ExperimentSituations value? This is a complete enigma! I had to reinvent this wheel to get everything else to work. GetExperimentSubject takes a biome ID as a parameter. What if the experiment is non-biome-specific, like flying Mystery Goo?

Now I'm gonna have that soundtrack stuck in my head all day... @KerikBalm You seem angry. Sure, the animations bother me. It's not a matter of realism in this case, it's a matter of looking good. This is all beside the point. The Mk2 crew compartment is unchanged - Mk2 tailsitters can use that as an entrance. Or use it as the cockpit to save weight.

Have you ever tried to climb a sideways ladder? I haven't, but it sounds hard.

Different door location on the cockpit...Laie doesn't like having to defy physics with ladder placement...hmm...I guess that's a valid concer-- Wait. Laie, don't you have a perfectly vertical door on that crew compartment?

It's weird that it's more uneven than the surrounding terrain. What's with the lumpiness? Maybe the KSC staff uses it as a sandbox of sorts? I've been using it more often recently. It's not so bad for low tech planes - taildraggers do just fine. Use Junos, apply pitch, and lift off by ~50m/s. Back in 0.9, though...*shudder*...the mk1 jet was too fast and too heavy. I always had to use the grass.

Exhibit A for 'why I'd like stock interstage fairings': engine clusters. For now, strut 'er up and let 'er rip.

Hey all, Coming back to KSP for 1.1, I kinda want to give the plugin API a try. I'm interested in fiddling with science experiments and new styles of data collection, but I'm not really sure how to instantiate new pieces of ScienceData. I need to figure that out before I can proceed with fiddling. Here are a couple of things that are leaving me a bit lost: 1) IScienceDataContainer seems to contain the function prototype for recovering data. However, the ModuleScienceExperiment class (which implements it) doesn't actually store data. Am I correct in assuming there's some external, possibly global, storage structure for ScienceData? Where is it located and how do I add to it? 2) By overwriting the location of an existing ScienceData within ModuleScienceExperiment, I can trick the game into recovering my homemade ScienceDatas. However, there are fields within ScienceData that I can't figure out how to populate properly, so it causes problems with the science archives. I can retrieve the base Experiment ID from ModuleScienceExperiment, but ScienceData appears to need something of the format 'ExperimentID@SituationID'. Where do I get the current situation? From the Vessel? What about the container ID? 3) Even if I had the right stuff in my new ScienceData, I'm not certain the new data would show correctly in the science archives. Where is the science recovery process handled? Do I have to register new pieces of ScienceData with some additional class for it to report correctly? What values are displayed in the archive GUI? 4) Where's the science? ScienceData has the number of Mits, but stores no actual science. ScienceExperiments show a base value, but not the current amount collected towards the maximum. How does the game keep track of collected science/data on a per biome, per situation basis? ...Now that I think about it, 3 and 4 are kinda redundant. へ‿(ツ)‿ㄏ Anyways, I'd appreciate any advice for science plugins in specific and the plugin API in general. Thanks!

Yep. Same here. And second launch, I opened the chute when the engines cut out. Tore it right off. As for my first airplane...I went through an hour of redesigns before I could get something to pull up and fly straight, but is still started pitching uncontrollably shortly thereafter. Eventually, I gave up and found a tutorial.

It's supposed to be an eyecatching 'hey you! you're using x64!' warning, I think. In case you got there by accident, here's how to get x64 to work for 1.0/1.0.5: I'll miss Nyancat in 1.1... EDIT: Oh, I guess Nyancat also comes out for april fools'

Always used Windows for KSP x64. I like Unix systems, but I primarily use my home computer for games and programming. Wine and/or VMs just don't suit my fancy. I finally gave up maintaining a Fedora install when I reformatted last Nov - I booted into it maybe once in the last two years. As for Windows...I understand the trust issues with the default info gathering and p2p traffic, but most of that can be turned off. When it's off, it doesn't collect any more data than Google. Or half the programs on your computer. Or the phone in your pocket that is literally tracking your every move. Welcome to the modern internet. If you REALLY want it all off there are antivirus programs that can help you, or you can block those ports manually. Aside from that, Win10 is largely alright. It's much lighter than the flaming garbage that was win7 and vista. It's customizable enough to satisfy me. And a well configured Cygwin gives you the unix stdlibs and bash, which tbh are the main reason I like Linux. Oh, and everything is made for it. Such as VisualStudio and C#. And Tortoise...and AraxisMerge...etc etc Call me a fanboy if you like, but I just want to provide a different point of view. It's more a pick-your-poison kind of deal, not a clear-cut-superior-software kind of deal. I just happen to prefer Microsoft's poison for now. As always, you do you.

I'm seeing some issues with Scatterer with the 64K rescale: http://imgur.com/a/m9s5Q The atmosphere is really bright and really opaque - especially in staging view! I created a scale-accurate setting with the config tool, but it didn't help. Messing with the nodes in Settings.txt works. Mostly. Still, I can't find a configuration I'm satisfied with. Does anyone have any tips about settings in 64k? Also, the third image shows a weird green line that appears around the horizon when it is occluded by terrain. Not sure what causes that.

The method won't take a dummy transform. I can't pass it "new GameObject('blah').transform.name": it will say "Cannot add attach node. Transform of name 'blah'". I'm not too familiar with Unity. Is this the model hierarchy from the Unity framework, or is it something KSP added? I thought creating a new GameObject would automatically add it to the Unity hierarchy. Anyways, here's my code for adding the node in OnStart: if (state == StartState.Editor) { Transform t = new GameObject("interstageNode").transform; ConfigNode cn = new ConfigNode("interstageConfig"); cn.AddValue("name", "node_stack_interstage"); cn.AddValue("transform", t.name); part.AddAttachNode(cn); } Actually, I just had a thought. Could it be that I'm trying to add the node as I'm bringing it up in the editor? I'll try adding the node outside of the editor when I get back to my computer tonight.