Diche Bach

Finally finished construction of my first Mun lander ship. I initially tried to do it "for cheap" and when I'd run it in "Simulation mode" (Kerbal Construction Time) I kept find I was cutting things very close on fuel. Found landing on Mun suprirsingly not too difficult: 1. Get down to about 10 or 15km 2. Burn Retro until horizontal speed drops from the ~550m/s down into the ~25m/s ballpark. 3. Descend from ~4500 m above terrain with periodic radial burns (well, at that point, that direction is pretty much retro too) combined with RCS translation burns to minimize horizontal speed(s). I managed to land it 3 out of 5 times in simulation mode, and now I just have to get enough cash to build the first instance of my high-fund Lunar expedition module. After fiddling with cheaper models (~250k funds and no bigger than 3.75m base) I decided to go for a solid "over-built" desgn that would leave plenty of margin for error on the delta-V supply. The one I intend to land here soon (for "real") costs about 800k funds but it will be worth it. Includes a 2-Kerbal rover, and command seats for up to 4 kerbals. The orbital service module will seat 6 and total mission endurance is in the 37-day ball park with 4 crew. After having some issues with geting the rover lose from the belly I decided to go with three pilots and a scientist. One pilot stays orbital (she has an Advanced Pilot Mission with a Mun flyby that will bump her from level 2 to 3) the other two pilots go EVA get on the lander and take a ride down to the Mun. Once landed, one pilot gets in the rover, and if the terrain is not ideal, rover disconnects, and second pilot will gently reposition the lander to a more level spot (thus a solution to nearly any "rover wedged under lander by enormous Kerbal head + slope issues). Once the lander and rover are disconnected and both are on surface, the science stravaganza will ensue. Based on what I was getting from simulation mode, I'll come back with something like 300 to 500 science which will be a nice topper to the ~750k funds and rep/sci rewards for the "Plant a Flat on Mun" mission. Took me a whole day of fiddling to finallly come up with this design/mission plan.

Holy Toledo! I thought I had a lot! Do you suffer performance issues? Would you mind post a screen cap of your GameData directory with all the mod sub-directories visible? I'd be interested to see what you are using. Here is mine. I count 76 folders now. Initially I had about 100 and found performance was worsening progressively. I saw performance improve a lot after pruning, but still feel it is less than optimum. Main issues now are: 1. Game takes several minutes to Quit; 2. Long sessions of building a large craft in VAB lead to very slow user-input responsiveness and thus require a reboot of the game from desktop. 3. Fairly slow transitions between session modes (Space Center to VAB; VAB to Tracking; Tracking to flight mode, etc.). 4. After a couple hours, I generally get a graphical glitch where transitioning from space center to R&D-> the R&D pane flickers into existence but then Space Center persists, even though R&D is in fact open (moving mouse can cause R&D pane to flicker in and out of view). Previously with ~100 mods, game would take 95% of 8GB RAM right at game start, and I'm not sure how much VRAM it was actually using. Allocating more to VRAM in my Windows control panels seemed to help a bit. Now with the reduced number, I think it starts out at ~5 GB used, and may get worse the longer the application is running, not sure. There presumably is an effect for more mods, even when each one is properly designed to minimize RAM use and is relatively bug fee. But I think that one or more of the mods I'm using might be particular sources of reduced performance. I have my suspicions which ones (just based on how the symptoms of reduced performance seem to follow on certain types of in-game actions), but have not made much effort to troubleshoot which ones. I'd be curious to hear if anyone spots anything in my list they think is problematic.

Thanks guys. Might have to try all of them at some point! But for now, I think my plain old Kerbol System career campaign will tide me over for quite a while.

So yeah, it was a "seat of the pants" project that turns out to be surprisingly successful and coherent, despite it being a first project for nearly everyone involved (at least at the start). Is any of that supposed to be a "bad thing?" Correct me if I'm wrong, but . . . this was their first game right? Seems pretty successful to me, and yeah: what they dreamed up initially has obviously evolved a great deal since then. I cannot fault them one bit; I'd be absolutely delighted if the first game I was involved in making was as good and as popular as this one is. It isn't like Squad is some vertically- corporation, treating their staff like serfs, developing products with purely analytical market-based conceptions and very little creative inspiration, and then selling people the Brooklyn Bridge and promising that if a user subscribes they will eventually turn it into a flying pumpkin wagon. Re: the "Tycoon Model," I have played Railroad Tycoon, only one. Considerably less sandbox, much less complex building mechanics, and a much more "realistic" setting (various scenarios but all are set in real Earth timelines). Fun stuff, and certainly different than career in this game. I agree career has a bit less of a "trying to win" and more of a "keep going this is fun" feel to it. I disagree however that it is impossible to "lose." I find I have to use "simulation mode" (in Kerbal Construction Time) a lot, and even then some missions/designs have to be retested multiple times before I am confident I can do them for real. Even with that provision, I allow myself to reload at my own discretion: meaning I won't reload if it was just dumb play on my part and a Kerbal got killed or $500K project went up in flames. But I will reload if it was a matter of me still learning a mechanic, or sandboxing to understand a part of the game better, or just seemingly weird random glitches (e.g., airplane taxiing hits a bump at 16m/s and explodes). I would see a "Tycoon" mode as being an alternative to career mode, not a replacement for it. But again, I think there are more important things for them to focus on for now: mod support/integration. I also think they really should be starting to think about Kerbal Space Program 2, else some sort of pay for DLC. It almost seems strange to me that they have not focused on any additional revenue other than sales of the base game. I hope that just means they are racking in the bucks and don't need to worry about additional products, because I would like to see this studio go the long haul, and be the source of many games to come. They have done a lot for their players, I think they cannot be criticized for thinking of their wallets: asking them to "redesign career from the ground up," for the stock game, at this stage, strikes me as asking them to take money OUT of their wallets and put it on the table. Asking for better mod support on the other hand: yeah, they will have to expend some resources, but a fraction of what redesigning career would involve I suspect, and moreover, they would have support from a significant chunk of the community (many expert modders around here it seems). The end result of this would not simply be a "different career mode that might appeal to some better" but instead: "better core support for mods = better running heavily modded builds = more mods being tried/more mods being built/more buzz on Youtube about KSP mods = more sales of the stock game, and better buzz for KSP 2 going forward. However, your suggestions/ideas/discussion does seem quite apt for KSP 2.

Thanks guys! In summary: 1. SSRSS (Stock Sized Real Solar System) = real "Sol" solar system "content" (Earth instead of Kerbin, Venus instead of Eve, etc.), but with everything retaining the scaling from the vanilla game, i.e., Earth scaled the same size as Kerbin (600km radius), Sol scaled the same size as Kerbol, Venus scaled the same size as Eve, etc. Thus, 2. SSRSS = playing SSRSS is pretty much just like playing vanilla KSP (from the standpoint of ship designs, required dVs, transfer schedulces, travel times, logistics, communications-ranges, etc.) except that everything is renamed to realworld equivalents and looks good. 3. RSS = same as above _except_ a. Doesn't look as good, and b. All the scales of everything are increased to reflect realworld volumes, masses, energy and distances? The result being: the Karman Line is at . . . 100km instead of 70km, Earth has a radius of ~6,300km instead of 600km (Kerbin-sized), escape velocity is 11.86kms instead of 2.74km/s (Kerbin requirement), etc.? So, does RSS actually "work?" It would seem like upping all the celestial objects in the game to realworld sizes (generally about a whole order of magnitude?) would be an incredibly complicated task from the standpoint of changing all the parts (engine thrust, tank volumes, etc., etc), and I was surprised to hear that such a mod (supposedly) existed at all.

Oh hold on now . . . Is this mod different from "Real Solar System?" I was under the impression RSS basically took the content in KSP and: 1. turned it all into its real solar system equivalents, AND 2. increased the scales/changed thus placing the required delta-Vs, velocities etc., close to real life equivalents?

Ah, so C# does suck just as bad as Java then eh!? I don't pretend to have mastered the use of pointers and data structures yet, but I'd much rather struggle to learn and use them effectively, i.e., write in C++. Skyrim, Stellaris, Jagged Alliance 2, Fallout 4: all designed with engines based on C++, all perform well with enormous numbers of mods (120 to 200 separate plugins) as long as they are not mutually exclusive mods). KSP, not so much . . . indeed KSP seems to handle heavily modded builds actually worse than Minecraft does. So am I being too simplistic or not quite getting anything right here?

Using assemblies of rapidly spinning electric wheels to orient space ships, and make self-assembling robots . . . We've come along way from cracking rocks into jagged chunks and hacking wildly at carcasses to cleave off something tasty . . . but most of us probably still operate at about that level

Oh, I'll have to try that Osprey!

No harm done! Before reading the lengthy explanations, I'm not sure how well I understood how these things work, but I don't think I was ever in the "it needs to be far from the center of Mass" group I still think that the primary source of confusion is that the game leads players to think that the model they are placing in their space ship is ONE wheel, when in fact, what it models in real life would be: a cylindrical container with three or four wheels inside it, each positioned inside the container so that their orientations are appropriate (either the 90 or 109 degree angles Snark refers to) and so that they axles are all attached to the space craft and can thus impart their torque (and receive their instructions for when to spin and how fast, etc.). If you think about it, it doesn't make sense that you can take A WHEEL and place it ANYWHERE attached to the spacecraft and have it impart torque in any direction, and I think this is really the source of confusion for most. However, when one considers three or more wheels spinning in an orchestrated manner it is probably much less counterintuitive. Am I right or what?

So in summary, they can be in any permutation of positions which fits two conditions: 1. The positions are all attached to the spacecraft. 2. The orientation of the axes of the wheels is appropriate for the wheels to be able to function as they are intended. There are many possible permutations of positions for three or four wheels on any given space craft which fit these two conditions. However, the wheels have to be connected to the space craft and the axes of the wheels have to be oriented correctly, so position obviously does matter. Saying "position does not matter" means they can be anywhere, even not on the spacecraft, and that is obviously wrong. Even given they are on the spacecraft, the three wheels cannot be grinding against one another: there needs to be space for each of them to spin freely, and given the orientation of their axes of spin have to be correct, this means that there is inherently a finite number of positions which will allow the wheels to function properly on any given space craft. A very large finite number, but not infinite, which is the required condition for me to accept the assertion that "position does not matter." But all of that is just theory. In practice, they need to be where it is best suited for the engineering of the craft, and this will generally reduce the viable permutation of positions from the very large "possible" set to a much smaller "viable" set. Why this is such a contentious topic I cannot fathom.

Glad to see this thread. My modded build gets pretty unplayable after a few hours, and especially if I spend a couple hours designing big complex ships in the VAB. Glad to hear that Squad is looking at ways to reduce RAM usag

I think you're missing a fundamental point of game design and marketing: they need to "aim" for a middle point. You do not necessarily represent that "middle point" of their market, and neither do I, or any specific individual. Perhaps your desired changes do represent the consensus of a sufficiently large segment of current or potential users that the changes you propose would improve customer satisfaction or sales; or perhaps you do not. All you can really do is state your case and let Squad decide, but in the mean time, the game is highly moddable and there are lots of good mods available, of which you apparently make use anyway. Rather than suggesting specific features, what I believe would be more conducive to the general well-being of the community and the game, is to suggest better mod integration. I realize that the game underwent a watershed in improved performance about a year or so ago when they rewrote their code to make use of 64-bit processors; but in my experience the game is still not optimized for heavily modded builds, and no one with the talent or inclination has come forward from the community to implement something like the mod management programs that exist for games like Oblivion, Skyrim and the like. Without Wrye Bash, Loot, and even to some extent Nexus Mod Manager and/or one of the newer incarnations, the modding community for those games would likely be a fraction of its current extent. Given the staggering number of mods, some of which exceed professional quality, and the sheer volume of Youtubes that deal with modded Skyrim, it seems fairly reasonable to conclude that: making their games not only "moddable" but relatively optimized to run well with heavily modded builds, combined with some luck of devote and generous community members who developed plugins that further enhanced playability for heavily modded installs. In my opinion, this is presently what Kerbal Space Program needs far more than anything else: better mod support. Make it easy to run lots of mods, make it eas(ier) to make mods, and promote "vibe" about mods, and the sales will climb, and even though some folks may decry that "the designers are letting the modders do their work for them" the truth is, a game has to be designed to be moddable in the first place. If everything ANYONE wants from a beloved game is available from mods, AND using large numbers of mods is easy and generally trouble free, why would anyone expect the studio to implement all of that variety into the stock game? NOT implementing the variety, but making all that variety EASY for the user to acquire is the way to go.

I was thinking of giving this mod set a whirl, but I don't want to "lose" my current playthrough. I figured the sensible option would be to: 1. Create a directory called RSSdependencies someplace outside GameData, and download all the sub-directories needed for this mod. 2. Whenever I want to play with RSS, copy paste the sub-directories from that "storage" folder into Game Data 3. Whenever I want to play NOT with RSS, delete those sub-directories from Game Data. Seem viable? Or are there lots of files from Squad or other widely used directories that get overwritten? That does not seem to be the case with very many mods for this game, but I thought it wise to inquire.

I play with the USI Survivability stuff (so many sub-modules i cannot keep them all straight, but one of them is Life Support) so I find Life Support adds a lot to the game. What I find still lacking there though is "food" seems to be all that is considered, with "habitation" "homesickness" and "electricity" figuring into as well. What about "air?" I guess we are meant to conclude that every Kerbal module with passenger capacity has air scrubbers sufficient for its crew capacity . . . A minor complaint so minor as to be not even worth mentioning really . . . Still, I voted NO. I don't think Life Support should be in the stock game, or if it is (and simply "using" the USI stuff would seem like a wise path) then simply make it a toggle on/off option and then with a settings pane like in the USI mod. Had you made: "Include it as a user configurable option (on/off, etc.)" I would've voted that way. In fact, I think Squad should pretty much take my mod list, and incorporate all of it into the stock game (as user configurable options! ) maybe if the code for all these mods were optimized to work closer to the source code it wouldn't be such a RAM hog . . . The one thing I have yet to find a mod for, which I think is the most egregious area for improvement in the game, is the flight planner window. The apparent lack of configurable options, or use of alternative user-inputs (right-clicking, shift-clicking, etc.) to open up various options panes in the flight planner is one of the things that nearly causes me to rage quit the game from time to time. Sometimes you just do not want to see all those mission waypoints cluttering Kerbin whenever you are trying to plan a precise maneuver . . . or when the multiple copies of "Kerbin Apoapsis" for a series of maneuvers start to clutter over one another . . . or when the stats for a rendezvous point are only visible by twisting and tweaking the camera into some weird angle so it isn't obscured by the "Kerbin Periapsis HERE!" marker. I would pay for the game all over again if they just put all their effort into improving the UI and functionality in the Flight planner for one work cycle and released it as a pay for DLC.

You can tailor it however you want by installing mods, tweaking settings in those mods, and even making your own mods if something still doesn't suit your tastes. Check out these Kerbal Construction Time RemoteTech ScanSat DMagic Orbital Science I play with a set of about 60 mods and out of all of them those are the ones that I think make the most difference in making it feel more like a "real" space program (as real as waddling little green people can be). I also really like Community Tech Tree and Connected Living Spaces, Ship Manifest and pretty much anything made by @Nertea I can recommend others that I think enhance gameplay at request, but I'll leave it at that to start. The other one's to check out (which I have not used but which I guess are quite good) are FAR and Real Solar System. Add those to that list above, plus Kerbal Interstellar Extended and one or two of the solar system expansion / extrasolar systems mods and you've got one helluva spicey meatball. Even with all that, I agree the contracts are a bit "plastic," but as games go they are pretty damn good really. I've got several different types of contract packs installed and some other plugins that enhance the role of contracts in the game. There are some contracts that I just always decline (and I have the settings I'm not penalized for that, I don't need to be punished for refusing to do stuff I find unfun in a game).

Despite repeated complaints by players over the decades, there has yet to be invented the "perfect" game, at least not in everyone's accounting. This is why contemporary computer games which strive toward a "flexible" design that affords an optimum middle ground from which modifications can more readily be applied, and a design which also facilitates modding--while also offering coherent game play in vanilla form--are a better arbitrary standard for judging the merit of a popular game than any given forumites' notions of ideal. If the game sold, it was "good." If it sold well, then it was "excellent." If it did that and it was innovative, then it was superlative. If it did all that _and_ it broke sales records it was stellar (Minecraft for example). Note, out of any given 100 gamers, nearly half may find Minecraft to be repellent, and for perverse reasons, any given one of these may feel it edifying to post threads on the Minecraft forums suggesting how bad the game is, even though.

Interesting Rocketeer, however, another question: I could almost conclude that what you are suggesting is that: "any position of the three or more wheels can function equally as well as any other position, and for equivalent 'cost' [time, energy, wear-and-tear]." That seems rather counterintuitive, and is probably not what you intend to mean, but as I say, it seems one can go from what you are saying to that extreme. Let us say we have 100kg spacecraft. We have (I don't know my physics at all . . .) 10 watts of power allocated to our reaction wheel part of the project. The craft needs to be able to achieve 10-degrees in any direction within 30 seconds of receipt of a maneuver command, and with no more than 0.001 degree of error within +/- 1 second (something like that). The unit cannot generate more than 1-degree Centigrade of waste heat, and the unit must function for 10 years minimum. The unit overall cannot weigh more than 2.2kg and it cannot cost more than $50,000 . . . yadda, yadda . . . . If we have specifications like this that we need to meet in designing one of these, then the theoretical "any position is possible" has to go right out the window eh? For any given purpose/specifications, there will be ONE or at least a narrow range of configurations for the wheels inside the given reaction wheel assembly that will serve well, no? But again, the position of the module itself is irrelevant, except for wobble . . .

Another way of saying: any positioning is possible as long as it is the "correct" position, in that only positions that allow the wheels to function as intended are possible. It makes sense that there is a wide range of possible positions that can work, but given the the specs of the wheels and the way they will function it would seem to me that there is one ideal position and that the further the wheels are from that ideal relative positioning the less efficient it will function. Seems to be some fascinating engineering innovations underway in this area! ADDIT: Hah! I love the top-rated comment on that video: One question that emerges though: I see that several of these have the wheels in a similar arrangement (the 90-degrees relative to axes of spin like Snark said above). But what about the "4-wheel" model (three with a backup) in a tetrahedral arrangement I see referred to in various wiki and youtube sources? What the heck does that look like? I guess the four wheels are arranged flat and centered on the faces of the tetrahedron?

Well correct me if I'm wrong, but the positions of the wheel_s_ DO matter. It is the position of the assembly of wheels that does not matter. The assembly torques itself by virtue of a set of wheels inside it. It thus torques anything it is attached to, and it doesn't matter where it is attached to it. But for any given set of wheels, they must require a particular positioning relative to one another (spacing, orientation, the whole nine yards) inside the assembly of wheels. It is okay if we don't understand this stuff and can just muddle through it as fellow gamers, eh? It is after all not a conference on rocket science at which any of us are posing themselves as professionals. ADDIT: here is what a "real" one looks like. Pretty much what I expected.

It seems to me the point is: the relative positions of the spinning wheels do matter (if their orientations are all that matter then they wouldn't even need to be on the space craft now would they?). The prevailing confusion on the topic comes from the misconception that a "reaction wheel" in game is meant to represent ONE wheel, when in fact it must be representing a module with multiple wheels in it, three, four, whatever. It is the combined spinning of these electric motors which can produce torque in any direction, thus the position of the "reaction wheel" (really more accurately the "reaction wheel assembly") on the spacecraft doesn't matter, as long as it is affixed to the spacecraft with sufficient adhesion, the computer that runs it knows where it is (and thus how exactly to spin it's innards so as to achieve any particular torque), and the specs of the assembly itself are sufficient for the craft in question (how much electricity does it require, how much heat does it generate, how big is the asembly, etc., etc.). Obviously, in order to function as an assembly, the wheels need to be within a certain proximity to one another, and mounted on a common frame and with the correct spacing relative to the orientation of their axes and the range of velocities at which they will spin. I'm going to go out on a limb here and guess that smaller wheels can manage the same effect as bigger wheels but they have to be spun faster and/or spaced farther apart? ADDIT: little daydreamy thought I just had . . . Nano Reaction wheels!

Pedantic much?

Well apparently the position of the spinning thingies inside the "reaction wheel" assembly does matter, even if the position of the assembly itself in the spacecraft doesn't matter. I suspect this is what all the confusion relates to: the cylinder model we place in a spacecraft in the game is not meant to represent a single "wheel spinning." It represents at least three if not four wheels spinning (inside of it) arranged in geometry that allows their combined spinning at various revolutions to exert torque in any direction. No?

I guess they had to start somewhere eh? Probably occurred to them briefly that "long-term this will not work if we try to build additional solar systems into the game . . . ah to hell with it. We don't even know if people will buy and play this thing. We need a game, pronto!" Taken from another perspective: even the Milky Way orbits "something" (some barycenter out there somewhere in the Universe) so if you try to solve the problem going in the other direction, where do you draw the line? I suppose a base game that included a barycenter for the galaxy Kerbol is presumably a part of somewhere way out there (just in the math) would have been better, but I can only imagine how that would screw with the rest of their game, given it only models "two body" systems instead of "N-body" systems or whatever?

I'm curious, why does an artificial point inside kerbin solve the problem? Does the stock game work based on a point on the surface of Kerbin? I'm sure the physics will go right over my head, but still curious nonetheless . . . I still marvel like a chimpanzee throwing feces when I use an elementary school kid gravity assist and save myself hundreds of delta's Vs.