MisterFister

Meh. I think the person you quoted was actually attempting to suggest that the engine be modified to allow axis-inversion or somesuch, allowing you to do things like turning a part inside out. (A left-hand glove, turned inside out, will fit on the right hand.) Easier said than done, I'll grant, but if done well it would reduce or eliminate the need to actually model (and load textures for) externally-inverted parts.

Also, to Bac9 -- 5.2.2 is now live on KerbalStuff! I just got the notice email and downloaded it, I'm installing it now. The description text on the KerbalStuff page still manually lists 5.2.1, but the file I downloaded was indeed 5.2.2!

Editor Extensions: http://forum.kerbalspaceprogram.com/threads/38768-0-24-Editor-Extensions-v1-3-19-Jul-2014-(EdTools-Editor-Tools-replacement) Part Highlighter: http://forum.kerbalspaceprogram.com/threads/50143-0-23-5-Editor-Part-Highlighter Part Angle Display: http://kerbal.curseforge.com/ksp-mods/220831-part-angle-display RCS Build Aid: http://kerbal.curseforge.com/ksp-mods/220602-rcs-build-aid (just because) TweakScale: http://kerbal.curseforge.com/ksp-mods/220549-tweakscale StageRecovery: https://kerbalstuff.com/mod/97/StageRecovery These are the links that I consider either very useful or downright essential (depending on the mission profile) for use within the editor. Of particular note, the first one allows you to essentially build all craft from a single game scene (either all from the VAB or all from the SPH) which has the benefit of making all of your saved craft and subassemblies be visible within the same editor -- no more having to exit the SPH to go to the VAB to find your craft files! Or worse, having to design a space-only subassembly (with rotational / VAB symmetry) save it, tab out, copy the subassembly folder from your VAB to your SPH, to go back in, exit the VAB, enter the SPH, and then find it in your subassembly folders to load it into a spaceplane cargo hold. It seamlessly launches to the correct instance of Runway / Launchpad from the same building, too, if you were going to ask. Lemme know how these work out for you.

Unless you're in my sitch, using Interstellar, a mod bundled with TreeLoader. I manually moved the packaged tech tree into my persistence folder, so, disaster averted. Still.

In order: I just got reorganized on my mod-hunt. I have a KSP folder in my bookmarks list. Within it, three subfolders: one for KerbalStuff, one for Curse, and one for the forums. When I find a mod I like, I save the link to the download page (favoring them in the order I listed here.) Also, within KS and Curse, I always favorite / subscribe to the mod updates. It is often helpful to manually rename the bookmark link to something that you can remember, especially on the forum, since the bookmark title takes from the page title, and the [WIP] and [PLUGIN] tags aren't helpful to me on my bookmark list. As for searching for mods, you're correct inasmuch that the forum's own search tool is sometimes clunky with a lot of false hits. Google, however, is a godsend in this regard. If I know the name of a mod I'm looking for, a google search will very rarely list what I'm looking for later than the fourth hit or so. Hence, why I started using bookmarks. (I have 120 links that I've saved and tracked this way. Tedious to set up at first, but so wonderful once it's going. I even alphabetized my links once I had them all. ) And, point of fact, Kethane is absolutely by no means defunct or "replaced." They're two separate mods. I like to think of Kethane as a liquid-resource extraction, such as petroleum (and methane, from which the word "kethane" is derived, is itself a hydrocarbon derivative of petroleum) whereas karbonite seems more suited to simulating dry mineral extraction, with ore concentrations and veins and somesuch. I use both. And KSPI is still valid. It is through Interstellar that I am dependent on karbonite, in fact.

I don't "know," but I have some ideas on your issues. With respect to the inversion of your flap mirroring -- it sounds like you're dealing with rotational symmetry (as in the VAB) instead of longitudinal symmetry (as in the SPH.) I run a mod called EditorExtensions, available at http://forum.kerbalspaceprogram.com/threads/38768-0-24-Editor-Extensions-v1-3-19-Jul-2014-(EdTools-Editor-Tools-replacement), which allows the tab key to switch function between the two modes while remaining in the same editor scene. It's useful in both the SPH and the VAB scene. When designing payloads for spaceplanes, I can go the SPH where the plane is saved in the craft list, put myself in artificial VAB-mode, design my satellite, save it as a subassembly, and then hit tab to switch back into SPH mode before loading up my plane. Load the new subassembly payload, place it, check my CoM / CoT, and I'm good. Opposite, I can use the VAB, design a properly longitudinal rover with my tab key in artificial SPH-mode, and then switch to VAB mode before installing it as a payload on a vertical rocket. The differences in the modes have always been subtle. Even if you don't run the mod that I linked to here, I suppose it might be possible that something else is skafoozed and the symmetry-mode has been switched. If that is the case, it sounds like the underlying problem would be rather tedious to troubleshoot down to. At any rate, it doesn't sound normal. As for the collider edges so you can surface-attach stuff to the leading edge of the wings. Well, not to advertise, but that mod above has some functions that could mitigate your inconvenience slightly (a rudimentary, semi-reliable vertical snap function, or controlling the angle increments of the default horizontal snap) but generally, just use the WASDQE keys with the shift key. Setting your mouse to a higher resolution may help, too, or using a higher precision mouse pad (or just cleaning the gunk from the sensor and mouse surface -- if you own pets, you'd be surprised where the cat hair and dog hair can end up.) And on struts. I've always been under the impression that struts DO increase joint strength, though you might be incidentally correct with respect to the fact that they might not be able to strengthen a joint infinitely. The invisible struts are the exact same thing, simply with an intentionally-omitted texture. For hiding the struts internally, if you're referring to the internally-clipped strut end points, that's just really detailed control of the scroll and zoom functions while assembling them. If your mouse doesn't have a scroll wheel, replace your mouse right away, and use that scroll wheel to zoom inside your parts to make internal strut attachments. And finally, I'm not sure what the diffs are between the control surfaces. Run some FAR-tests on them and find out. At this point, I'm willing to believe that it's just a difference in texture. Hope that helps! And if someone else sees an error in my advice here, please set me straight.

Might there be any plan to reduce the following? (Particularly RPM, HR, MFT, and TweakScale) And what exactly does that last line mean, please?

You're instinct is correct; analyzing the data in the lab will not increase it's Kerbin-recovery value. It will only increase the data's transmit value. The point made elsewhere, however, suggests that if you can generate duplicate samples, you can analyze and sample the first, and return the second, for a total combined value that is slightly greater than if you'd just returned with a single sample. So, pros and cons. Nevertheless, even with single-sample returns, the mobile lab would still be needed to clean and reset the experiment modules between landings.

{I could've sworn that I replied to this earlier.} High praise. Thank you. My walkaway from your reply is that my ceiling for ever learning how to read these will be capped by my inability to program. It sounds as if your experiential knowledge is based primarily on things you've had to troubleshoot previously from a coding / modding standpoint. I did a lot of neato fun things in vBASIC back in high school twenty years ago (jeez it frightens me to say that!!) so I understand the general mentality that it would take. But I have NO basis in any C-derived environment. With respect to #2 in your reply, I hope I didn't convey the impression that I was crashing in x64. I stopped trying to get x64 to work last weekend. This is an x86 issue. And on #6, thanks for the spot. I thought I'd cleaned out all duplicate MM files. With respect to TweakScale not working, you're correct that I wasn't happy with it, but I could get it to work (partially...?) in the Control Group editor. I'd chalked up my difficulties to my own poor familiarity with the mod. I'll re-assess now that I've cleaned out the MM and update you further. Also, What are your thoughts on this? http://forum.kerbalspaceprogram.com/threads/94086-x64-works-%21-But-I-don-t-know-why%21-Please-help-me-replicate Someone else seems to think that by converting texture files to the tighter PNG format, memory footprint can be vastly reduced. I think his own context was in attempting to remain below x64's instability threshold, but for my own x86 purposes here, if he's onto something, it could help me here. Just so I'm clear on what you were conveying, you see no blatant evidence of an improperly installed mod, or a freakishly serious mod intercompatibility issue? In other words, my memory overflow theory still works as an explanation? Which leads me to another point: I posted that thread (the one I quote Majiir from, above) a few moons ago. My understanding from back then was, "nice idea, but so far no dice." In fact, it was Majiir's own explanation that led me to abandon my plans to take a few hours, run mods one at a time, and take Task Manager snapshots of my footprint with each one. It occurs to me now that memory-usage utilities have to exist somewhere, even if not for KSP. I'll run my own googles myself, so no worries, but does anyone have any head start info on where to look?

Yowza. And I thought I was mod-heavy. So, correct me if I'm wrong, you think that if the problem with x64 stability, regardless of "cause," is triggered by high memory usage, and you can convert texture files to a RAM-efficient alternative format (thereby reducing the footprint of those textures) then you can effectively remain below the x64 instability threshold? I might look into this and provide feedback. At any rate, it may end up helping me with my x86 issues.

Hello folks. I'm running KSP 0.24.2 x86 on Win 7. My system incudes 16gb of RAM. I'm a mod-happy little nimrod, currently running approximately 100 mods, give or take. I run ATM at the default-aggressive level, though I know it's possible to make it even more aggressive if I don't mind making everything almost ugly-blurry by manually tweaking its config file. I was told by none other than Majiir, the creator of kethane itself, a while ago said ... I think that's what I'm running into here. I know that the normal troubleshooting steps calls for me to strip down to a stock-only install and reintroduce the mods one or a few at a time, but in my case, that would actually make my problem MORE difficult to track if it is indeed a RAM overflow issue. x64 is no help either, since it's widely-enough considered to be broken that it's not even supported here on the forums. I want to learn more about this than I do. I have my output_log.txt at this link, and I know that there is a trove of information in that file, but I don't know how to read it. I don't know how to make sense of it. I do know that I throw a crapton of NRE's which become visible when I open up the debug menu in-game, but they're anonymous and I can't make sense of that info either. As for steps to reproduce my problem, the fact that it's difficult to predict when it happens lends credibility to my sense that it's a plugin-driven RAM overflow. Like I said, I run about 100 mods, and while only B9 / KW / NovaPunch are part-only mods, I do have a fair number of mods designed for VAB / SPH use, to include KCT, Fusebox, Editor Extensions, Part Highlighter, MJ, KER, and some others. To generate this specific log, my game CTD'd when exiting the VAB to the KSC main screen. Can someone help me figure out how to read this? I mean, sure, if you can read it and tell me right away what you think the problem is, that's great, but I'm specifically asking for you to help me learn how to read it for myself. If you do provide a troubleshooting opinion, can you show me how you arrived at it? Thanks!

The Steam version of the game includes both the x86 and the x64 versions. The default icon that goes to your desktop (if you chose to have one) runs 32-bit (x86) through the Steam client. To run x64 you have to manually select the file and / or modify the shortcut. In other words, you already have 32-bit KSP installed. Just run ksp.exe.

That is from the B9 forum thread, at http://forum.kerbalspaceprogram.com/threads/92630-0-24-2-B9-Aerospace-Release-5.

You're asking for replication. What mods would you suggest we use? Even in x86, different mods can have poor interactivity and incompatibilities.

That is from the B9 forum thread, at http://forum.kerbalspaceprogram.com/threads/92630-0-24-2-B9-Aerospace-Release-5.

Another possibility is to do a much shallower reentry. Dynamic load stresses are proportional to both speed and air density (EAS). If unpowered, speed isn't very controllable, but air density is. You would need to bleed off speed while remaining at higher altitudes for longer, before descending to the lower strata of the atmosphere. Depending on how conservative your bleed-off passes are, you may need to perform multiple orbital passes. It's been a while (and a few FAR versions) since I had an assembly like yours that would have required this, but if I recall correctly, the sweet spot is when I can get the AP (on stock-size Kerbin) below 80km while still keeping PE above 60km. MUCH easier said than done, I'll grant, but once that scenario plays out, you likely won't have enough speed to remain aloft for more than one more orbital pass.

I mean, whut?

Just started KSP about half an hour ago, and AVC reports that there is a 5.2.2 available. KerbalStuff and this thread still only read 5.1.1. The AVC flag doesn't end the game, but it is a curious sequence. Perhaps the 5.2.2 upload is pending moderator approval of some kind?

r4m0n not being around does suck in the overall sense, since he was IS a great modder. That said, I don't begrudge anyone for going dark, as I do it often as well. That said, I've run into a problem with KSP Interstellar, one of the mods that packages this mod. I posted there recently about how up until earlier this week, TreeLoader worked the way I've grown to expect it to, but somehow it stopped working at the first-run tree selection screen. This mod is apparently not communicating with the online tree repository, or the repository itself has gone dark (perhaps r4m0n's subscription to a host has expired or lapsed?) Can anyone confirm this? Can anyone "see" within the code of this mod to identify the repository so that someone, perhaps even I, could manually try to visit it in a browser to either confirm, or manually download and install the tree I'm looking for? (Interstellar does ship with its own custom tree, but TreeLoader always prompts me to install an update to it and restart KSP, so I'd prefer the updated version if at all possible.) Note, I am not complaining, nor am I asking someone to fix my problem for me. I just don't know how to proceed, and I'm hoping that someone else can provide me some guidance.

The odd camera wobble issues sound like it might be a perspective change that is "supposed" to automagically happen when you transition to an orbital state (when your PE climbs to a certain altitude.) Depending on your ascent profile, if this PE "hovers" momentarily at the camera's transition threshold, then the camera may spend a few seconds hesitating. Given that RO alters the size of the planet and, proportionately, the atmospheric altitude and density profile (the edge-altitude reaches higher than the game's default 68km) but cannot alter the camera's orbital transition threshold altitude, this might contribute to camera hesitation, especially if the ascent profile would be prone to causing such hesitation on stock-FAR Kerbin anyway.

Everything described here is true and useful, but I think the OP implies that it would be helpful to know "why" this happens. First, it's true that realworld GSO satellites drift and have to consume fuel for stationkeeping purposes over their operational lifetimes. I highly recommend the wikipedia pages for this topic, and I specifically refer you to mentions of "graveyard orbits." Generally, realworld orbit perturbations result of myriad underlying causes, including faintly off-kilter calculations to begin with, along with fuel impurities (resulting in slightly-less-than-optimal thrust vectors, resulting in burn times being minisculely off-mark) and outside gravitational influences. Over extended periods for extremely accuracy-sensitive satellites, influences such as the moon's orbit, solar activity, and minute irregularities in Earth's own gravity well (resulting from variations in the distribution of mass in the Earth's liquid or semisolid mantle). Also, there is something called interstellar and interplanetary drag, such as the cumulative slowdown you get from floating through faint dust clouds and debris stemming from Keppler Syndrome, as well as naturally occurring events such as the leonids. Obviously, since KSP is a game, the Unity engine is not designed to (nor could it ever) faithfully model every single one of those conditions. Indeed, in KSO all SOIs are perfectly spherical, because each planet's mass is perfectly uniformly distributed, resulting in a featureless gravity well. For example, there is no such thing as lagrange points in this game. All fuel is uniformly pure, as another example. There is one obvious issue with maintaining accurate KSO paths and two subtle issues. The obvious issue is human input, just as with realworld. If you design your maneuver nodes well (which even then is not entirely sufficient for the accuracy we would like due to the two subtle reasons below) it's still necessary to aim and burn them well, too. Good form and fuel efficiency on maneuver nodes begins with good calculations in the VAB / SPH, and continue to include dividing the total burn time evenly across the node point (for example, a sixty second burn should hypothetically begin exactly 30.00 seconds BEFORE the designated time, and end exactly 30.00 AFTER, though with the fraction of a second it takes to actually go from zero to full throttle, this is never exactly possible) and accurately following the node indicator on your navball -- when you are down to the last few m/s of burn, it's generally a good idea to lower your throttle, puff those final m/s out, and actually follow the drifting node marker on your navball whenever possible, since the location of the marker DOES calculate your new trajectory live by applying any burn imperfections into the original node calculations. Generally, everything I've said so far makes an immediate sort of sense, when it's laid out. The two other reasons why KSO orbits drift the way they do are much less obvious, however. First, we can agree that the actual math (advanced conic calculus) that goes into figuring and plotting (and subsequently simulating and rendering) any non-linear path, either through realworld space or through KSP space, is highly complex, with numbers that have unending decimal places. Simply put, in order to "work," the game engine at some point is forced to say "that's close enough" and stop calculating past the umpteenth decimal place and just fly with that. Those rounding errors, particularly when projected forward over simulated time lapses, become significant -- ESPECIALLY in a situation like yours where you have multiple satellites involved, and one realizes that you can run the same calculation a hundred times, and round it the "same way" each of those hundred times, and little eensy teensy discrepancies become more and more noticeable. As if all of that wasn't enough, there's also the fact that when coming into and out of time compression, and when OTHER craft in your savefile change SOIs, all of those calculations are reset and recomputed... and re-rounded. As you play your game, whether you simply blast forward at 100,000x time compression for 5 realworld days, or you simply place a satcomm network for RemoteTech2 and then go about your merry ways, this repetitive rounding will compound and worsen all of the above factors that I've described, each time the engine calculates it, which can often be hundreds of times every realworld second. (FYI, the fact that it crunches such heavy numbers is the specific reason why this game can become a slideshow when it has to keep track of large and complex craft in close proximity to each other, even without dark NRE strings.) So, ultimately, there is nothing that any player of this game could ever do, including savefile editing, that will absolutely eliminate this problem. Savefile editing will, of course, come the closest to totally eliminating it, since doing so will eliminate all of the human-introduced and even a significant portion of the game-introduced factors and floating point errors that I described above. Ultimately, just as in realworld satellite maintenance, you just have to in some way incorporate this inevitability into the design of your craft and your mission profiles (for example, by periodically re-editing your savefile, or by launching more satellites for your network, so that when one drifts out of position, it won't IMMEDIATELY result in a blind spot in your coverage, and by launching those satellites with extra RCS for better finetuning over a longer operational life.)

No, I'm good, though thanks for asking. I found in THIS mod's download an outdated .dll for one of its dependencies. I found a current .dll from that dependency's own main download, which I had to obtain separately. I replaced the .dll, and we're good. My only suggestion was to update the download to include the updated .dll within the bundle. I presume that there must be one or two users out there, new to using mods, for whom such self-service would be daunting. (I can most assuredly state that my confidence in managing mods is now WAY higher than it was when I started.)

My KSP Interstellar save was working in x64 last night when I logged off. After converting back to x86 due to stability issues that had nothing to do with this mod, I started and began a new career save. The MuMech Tree Loader is reading blank with no entries listed of any kind in the tech tree dropdown box. Two questions -- first, since none of the changes I made were to any of the Interstellar mod's folders, does anyone have any idea why this may have occurred? Second, screw the treeloader, how would I just run the standalone Interstellar tech tree and nothing else without the dropdown? (I get the feeling that the answer to my second question is deceptively simple.) PS -- Every new save always asked me to download an update to the tree and then restart KSP. Never understood why that is. Could this have implications to my problem here? And in any event, how do I pre-download the updated tree so as to not have to worry about starting KSP twice for the first session? Thanks!

Question for the OP -- How "primary" is the KerbalStuff download? I like it because it seems to contain all the dependencies needed, especially for an ATM-aggressive x86 install like mine. Nevertheless, the RSS .dll included with that mod flags as being for 0.23.5 and is rated as "incompatible." Replacing that file from the RSS download itself solves that problem. Would you consider updating the KerbalStuff release to reflect this? Thanks.

^^ Might wanna take a look at the resolution pack for this mod. There are three versions of this mod, low medium and high.