MisterFister

Worse yet -- the link from the Curse page to this forum thread is also corrupted. Here's your direct download link: http://kerbal.curseforge.com/ksp-mods/220521-rcs-sounds My question: RSCSounds.version very clearly lists this download as v4.1 (just downloaded 4.1b for the third time, in fact, just to be sure) but AVC recognizes this as v1.1 and it throws a "you need to download the new version" prompt. Is there any way to fix this?

Thanks for this!! Very helpful.

I have to say, I've been running this experiment for the past week or so, and x64 seems to be as smooth as butter for me after having converted those texture formats. This is not to say that it's been crash free, as even x86 crashes. While it's true that I hadn't been keeping "thorough" track of my crash-rate before this experiment, I estimate that with average play sessions of approximately 2-5 hours each, I run into a crash approximately once every 2-3 hours or so, give or take, and that this is roughly comparable to what I got on x86 as well. My memory footprint trends ~6.9gb at title screen with this setup, with no ATM. I've been posting my partially annotated output logs to https://www.dropbox.com/sh/escqxych4z180de/AAA4FyP6t2NccUz6b5cBgodxa?dl=0, which is also where you can find my original experiment stats. The only "new" symptom I can report after extensive x64 usage isn't technically a new symptom at all, just a new manifestation of an old one. Previously, it did occasionally happen (both in KSP x86 and outside of KSP entirely in other programs, including once in a web browser, and a handful of times over the years in other games) where my usb sound device would just go dead. This tended to happen, on average, after extended periods (days or longer) of Windows not being shut down and instead being slept or suspended between work sessions. The problem could have been fixed with a hard reboot or by unplugging-replugging the usb cable to the sound device. Google searches confirm that this is not unheard of in Windows including Vista, 7, and 8. (I currently run 7, but I recently downgraded from 8, and originally purchased KSP while running Vista.) Those same Google searches are wholly unhelpful, however, on revealing a cause. The new dimension to this issue since going feet first into x64 is that this seems to happen much more frequently now. While it can occasionally happen twice during the same Launchpad sequence, I can report that it SEEMS more likely to happen within the first 90 seconds after a KSP scene transition. This sound loss persists even after exiting KSP, but is quickly restored by the unplug/replug method or by a hard reboot. This suggests to me that it's not a KSP problem specifically, but something about the way KSP x64 (or Unity x64) addresses memory exacerbates an already known underlying problem. My personal, uneducated, suspicion, is that Unity and KSP both need memory streamlining that is a few versions off in the future, and / or we might have a memory leak of some kind. I do not anticipate abandoning my x64 play any time soon, however, even with this issue. I run AOL Instant Messenger (remember that?) and it's taken in recent weeks to throwing certificate errors at idle, so I may have other incentives to do some reworking on my system that would also address this sound loss issue. In any event, x64 with full-res textures is GLORIOUS and it feels like the way it's supposed to be played. I shall not willingly go back.

So, just so I understand: launching a Creature Comfort module and a kibbal container, by themselves, won't do anything? I need to also launch or connect it to the Science Lab that comes with the same mod? (Not the default Squad science lab?)

Pigpiling: StageRecovery, mentioned above, is a very great mod, and it's designed to work hand-in-glove with another mod by the same developer, Kerbal Construction Time. On both of those mods, the learning curve SEEMS a lot steeper than it is. Backup your savefile so you can revert as with any mod, but after a few launches it really does become very intuitive. I can hardly imagine playing without them now. DebRefund at http://forum.kerbalspaceprogram.com/threads/86691-0-24-2-DebRefund-v1-0-13 is another that attempts to accomplish the same thing as StageRecovery but it does so through different calculations (and is therefore not quite as seamless with KCT). If, however, you wanted to actually fly both stages of an aircraft, the closest I've seen is with a mod called FMRS, found at http://forum.kerbalspaceprogram.com/threads/80292-0-24-2-Flight-Manager-for-Reusable-Stages-(FMRS-v0-2-00). Currently being explored by YouTuber Tyler Raiz, it's a mod that "splits" your quicksave. First you pilot the primary / payload stage to orbit, initially allowing your secondary / spent stage to crash and be destroyed. The mod saves your progress with the payload, reverts back to the stage separation, and you then take control of the spent stage (while your payload crashes.) When you're done, the mod merges the two versions of progress into a new quicksave and loads it, so that your end result is two stages, manually controlled, safe and sound. Quite genius, I think.

In particular, launch / intercept windows seem to be peculiarly important, especially on limited dV budgets -- especially because even with MJ / KER, you'll never know your full dV (due to mass calculations) until AFTER you've mated. YouTuber iKerbals runs a, STS mission series. https://www.youtube.com/user/iKerbals/videos At STS-171, he manages a modded capture and begins developing an asteroid colony in circular LKO christened "Kerpophis." Kethane, Asteroid Resources, FusTek, KAS, and a few other mods feature prominently. Notably, he works exclusively with Helldiver Shuttle launches.

Accidental duplicate post.

I edited my data post at the bottom of the previous page. Note that one result called for ~6gb ram after load. I posted a dropbox link to my branched log files (mostly crash reports, but there were some non-crashes as well.) My own limitation on being helpful is that, beyond replicating the same steps to get to the title screen (which is how I built that data set in the dropbox link) I'm not exactly sure how to replicably "test" or "stress test" a modded install past the title screen, other than by "playing" it, which is very organic and not very conducive to reliable, replicable testing (I prefer career mode and career-mode-oriented mods) without going to sandbox or just waiting for the occasional rando CTD and posting the crash logs then, along with perhaps the career save folder for good measure if someone thought that would be useful. I can say, however, that I've resumed play on my career save in x64 using this texture-conversion technique (with a slightly expanded modlist from the one I'd settled on for x86, without ATM and with an idle RAM footprint at title screen ~5.8gb) and aside from a slight gameplay issue from having introduced a new mod that wasn't there when I began the save, I have to admit that x64 appears to be running gangbusters. My only frame of reference was an aborted attempt about a month ago to start a career save on x64 that resulted in me giving up due to right-click issues, massive z-fighting, and other stability issues that rendered my gameplay to be so unfun as to be borderline unplayable. From this point onward, I'll make it a habit to save all output logs after every gaming session, whether it crashes or not, so as to prepare for the possibility that I would run into a crash issue later on in my career progression (allowing for the output logs over time to document any evolving error trends.) I suppose I can just add them to my dropbox link if anyone would care to look.

The link for the forum thread is http://forum.kerbalspaceprogram.com/threads/59005-0-23-Release-3-0-Active-Texture-Management-Save-RAM-without-reduction-packs%21. From that thread's OP, the link I use is https://github.com/rbray89/ActiveTextureManagement/releases/tag/3-4. While it's possible that the link you quote would lead you ultimately to the same info, GitHub also allows you developer's access to the source code so as to make changes (for collaborative work on a larger project.) The links I provided offer, if nothing else, a cleaner (fool-proofer?) download interface. Hope it helps!

Scott Manley and TheWinterOwl on YouTube both have experience with this. TheWinterOwl in particular is a former pilot. For a crash course, feel free to PM me as well.

I'm wondering if we should be more detailed with our modlists when announcing replication of this project. Plugin-based seem likely to behave differently than simpler part mods.

I recall that I ran into this, too. Simple solution, I downloaded the RSS mod itself from its own thread and used the .dll from there. For my own personal archival purposes, I also replaced the .dll in the Better Atmospheres zipfile with the correct version. (I do the same thing with Firespitter where applicable -- I find that repackaged .dlls just in general tend to lag behind by at least a version or two.)

I figured this. My testing time is restricted to after hours, and yesterday was a long day. I threw my info up as a preliminary thing. Do note that when I get home tonight, I'll be editing this specific post to reflect what I find. Beyond prelims last night, I managed to get a lot of groundwork done. I downloaded and catalogued a few extra mods for stress testing purposes, extracted them to subfolders so I can compare hard drive footprint sizes, and set up a system to track my overall install footprints without necessarily having to disturb my previously-functioning install. OS: Windows 7 Professional SP1 x64, all OS / AV / AMW updates applied Chip: AMD Phenom II X4 965 3.41GHz RAM: 16.0 GB DDR3 1600 (RAM is capable of faster clock, mobo is not) MoBo: Asus M4A79T-Deluxe, no overclock Graphics: ATI Radeon HD 4895 (x3 on CrossFire) -- This is the earliest build that I ever encountered capable of running Crysis on absolute-max visual settings including 16xAA at 1920x1200 with absolutely no problems or stuttering of any kind, at the time on 6gb RAM instead of 16) OS HD: Kingston SCSI 256gb SSD KSP install drive: RAID+0 4x-array Kingston Velociraptors 256gb ea. / 1TB total -- dedicated to game / steam / "non-productive" installs Overall System's Windows Experience Index: 7.3 Aligned Currency Indicator Ambient Light Shifter Kerbal Aviation Lights B9 CactEye Orbital Telescope Chatterer Coherent Contracts CrossFeedEnabler (dependency) Custom Biomes DangIt DREC Diazo's Action Groups Extended EditorExtensions Enhanced NavBall FAR FinePrint Fusebox FusTek Station Parts GingerCorp Station Hubs Goodspeed KAS Kerbal Economy Enhancement Kerbal Construction Time KJR Kethane KineTech Animation (dependency) KipEng Low Profile Station Hubs KSP-AVC KW IR MJ2 MFT NavyFish Docking Alignment Indicator Nereid's Final Frontier Notepad 6S Service Compartment Tubes NRAP Part Angle Display Part Highlighter PreciseNode RCS BuildAid RCS Sounds RealChute RT2 SCANSat ScienceAlert SelectRoot Mk2 Cockpit Internals SirDargon's Science Container HotRockets! SP+ HexTruss StageRecovery StationScience TarsierSpaceTech TextureReplacer TAC Fuel Balancer TAC Life Support TriggerTech KAC TriggerTech ARP TweakScale USI DERP Universal Storage incl. KAS / TAC VesselView Vanguard Escape Parachute KSPI MM 2.4.4 Blizzy's Toolbar KSP Real Skybox (hi-def) Animated Decouplers ASET ALCOR incl. IVA and prop assets bdAnimation Module (dependency) Blizzy Ambient Light Adjustment EVE Better Atmospheres v5 Hi-res CLS CustomAsteroids (full, as dependency) DecoupleForX64 Distant Object Engine Ignitor Firespitter (full) SafeChute KSI MFD Improved Chase Camera RPM Kalculator Kerbal Flight Data NavUtilities KerbQuake CoolRockets Klockheed_Martian_Special (full) Kustom Kerbals LLL Modular Rocket Systems Node Resizer (dependency, full) NP Probe Control Room PWing PFairing PunishTheLazy Taurus HCV RPM Engine Ignitor (add-on) SDHI SMS ShipManifest TimeControl Vexcom RPM HUD WheelSounds My output files (either logs or crash-log-folders) are at https://www.dropbox.com/sh/escqxych4z180de/AAA4FyP6t2NccUz6b5cBgodxa?dl=0. Note the branching folder structure by x86 / x64. All readings either crashed on load or were taken at first title screen. When title screen appeared, RAM footprint was typed as name of otherwise blank .txt file (in "k" from Task manager). Apologies for the delay in providing this edit, as I got bogged down trying to do other testing past the title screen, but had a hard time streamlining the process and making it replicable. Disk Footprints: Total modlist, 2.59GB -- After switching, 1.97GB

I am rather perplexed to report that I may have replicated this OP's findings. I backed up my install, and ran the converter he suggested on my install as-is. I targeted all .jpg, .mbm. and .tga files to a .png output, auto-deleting all original files in the same process. Before compression Hard drive footprint = 2.16gb Memory footprint x86 (slightly extra-aggressive ATM) ~3.2gb at title screen, wouldn't run without ATM After compression Hard drive footprint = 1.65gb Memory footprint x86 (same ATM) ~2.6gb at title screen, still wouldn't run without ATM Memory footprint x64 (ATM removed) ~3.8gb at title screen I shall continue experimenting, and I would look forward to reports from others who have experimented so that I might compare results. I am skeptical, but hopeful. Included in the install are KSPI, B9, KW, Kethane, US, KAS, and some other plugin-based mods (exact list available upon request, though I specify these because of how part-heavy they are.) Also included in this install is TextureReplacer. Notably absent are EVE and Better Atmospheres, with which I may experiment for stress testing purposes. @NathanKell et al: is this a potentially valid proof of concept, or am I doing something wrong?

Just so we're clear on this control failure, this was x64, right? Cuz I've gotten to the title screen several times on x64 with 8+gb a few times. I managed to get up to 6.2gb with enough stability to launch a few initial flights in career mode before reality set in.

Not only that, crash-on-load issues with "no error message" often generates a new folder in the KSP directory, a folder named by a time/date stamp. I suggest deleting those, re-attempting KSP, and then checking after it crashes. If a new one appears, this lends strength to a RAM-issue theory. You mention KSPI and B9, both part-heavy mods. Part textures are the single greatest RAM-burden during load. During runtime, part textures continue to weigh the system down, but plugins can have somewhat erratic memory consumption. It should be noted that the B9 release page itself describes ATM (Active Texture Management) as "practically required," just by itself. There are two preconfigured versions, a basic and an aggressive. Download the aggressive, install it with preconfigured settings, and see how that works. If you do manage to get to the title screen, alt-tab out to Task Manager and see how much memory the ksp.exe process is using. If it's anywhere above 3GB (which is likely, depending on the exact extent of your mod list) then know that no matter what you do, you'll always be crash-prone. Consider removing mods, or at least pruning duplicate parts from certain mods.

It's important to note that mod memory usage is not static. A lot of plugins have "bursty" memory consumption. If you spent a lot of time tweaking your RAM-usage, then it's likely your idle is near threshold to begin with. One spike can ruin the party. (I know your feels, bro.)

It bears mentioning, in support of the OP here, that one of the very functions of the VAB / SPH editor DID originate with a mod -- subassemblies.

Ok then, new question. I downloaded all three resolution packs (High, Medium, and Low) and I'm getting the same error on all three of them. Trying to extract, remove, copy, or in any way work with [zipfile]\BoulderCo\Clouds\Textures\Laythe1.png generates "Error Code 0x80004005: Unspecified Error" in Win7. I can skip extraction, and I gather one of the cloud layers will be missing as a result, so all is not lost, but I'd still care to hear any advice on what could be causing this. Google searches come up nil, and mostly lead me to Microsoft Knowledge Base discussion threads that consist of someone pretty much describing my problem and receiving "support" replies on how to set up an MKB forum account and telling them to troubleshoot by rebooting and seeing if they can recreate the problem. :-\ So. Yeah. Anyone on this side of Kerbin got any clues? Additionally, I think the multiple layers of clouds around Kerbin are all drawing from the same texture file. Doesn't seem to be related to the problem above, but in any event, the clouds look to be duplicated -- kind of like when you see a 3d-image on a projector screen and you're not wearing the special glasses. Like there's an afterimage of some kind, or ghost trailing. Pics below. http://imgur.com/a/RVrSH#0

Exactly. That's why I shorted the TreeLoader mod and instead just copied the tree.cfg from the WarpPlugin folder right into my Save folder. *shrug* I might not have the latest updated tree from the TreeLoader server, but hey.

Actually, sorry, but no. Your picture is way too small of a thumbnail to impart any meaningful information. *shrug*

Thanks!

Please read my question. B9 is shipping with 2.4.4, which is NEWER than the one here. I asked if it was a dev build, or some other thing that I should avoid using.

B9 v5.2.2 ships with MM 2.4.4 (literally went live on KerbalStuff within the last hour or two). The latest listed on the OP here is 2.3.5, but a few posts above, there is a 2.4.2. Are these dev builds? Which one should I be running?

Sweetness! I'll do this right away. Yeah, I made that mistake a while ago and really pissed off Cilph in the RT2 thread. The varying organization of mod download zipfiles can get maddening. To reduce it, I've taken to prepping all downloaded mods with a blank .txt file, with a filename signifying the exact zipfile I downloaded it from. This allows me to do some of my own version tracking. Also, happy side effect, I found it's REALLY useful in uninstalling mods (for example, to reduce ram-load). A lot of GameData folders get joined or partially overwritten by multiple mods, such that deleting a GameData folder can break another mod if you don't replace that other mod's dependencies afterward. For example, my BoulderCo directory has ... six .txt files like that, so that if I wanna uninstall any of those, I have a list of other mods dependent on it, so I can reconstruct the dependencies after deleting the mod I wanna uninstall.