MisterFister

All info that seems useful, given my VM experiences in the last hour. And, hattip: I run Punish The Lazy. Cute little mod. I like it.

Respectfully, I don't entirely buy this. If you're saying that the native security settings within the OS itself are less prone to malware intrusion on a structural or infrastructural basis, well, then, maybe, with particular note to the fact that my Linux-virginity leaves me at a disadvantage in proving otherwise in any case. But to say that malware of any stripe doesn't exist in the wild strikes me as... idk. "Off." Malware does exist for Macbooks, for example, and I've seen it with my own eyeballs in person. While malware ecology would tend to favor Windows due to heavy market share by Windows (large target-share for malware) well, of course, the most varied malware diversity would then be for Windows environments. But I respectfully refuse, on principle, to go blindly into the night without so much as a leather shield against the things that go bump. I wouldn't use the word "paranoid," per se, to describe that, but I would agree that it is perhaps over-cautious. That said, I'm experimenting with a VM instance of Xubuntu. My specific and explicit problem would be departing my Windows environment. I would sooner need to get a second desktop tower built than run without my Windows due to work and school, that's not a brand preference, it's a harsh reality of my situation. That said, while the VM aspect seems to be promising so far, I'm having a hard time figgering how to actually install my AMD drivers, which I have downloaded btw. I'll tinker with it some more.

Thanks!! (10 chars)

I'm not entirely sure if this thread belongs under modded or un-modded support, but my instinct is that it belongs here in modded. Moderators, if I erred, please relocate this thread if needed. So, I have been a pretty luck guy with respect to Win64 stability issues and I note that v0.25 has changed that luck considerably. I archived my 0.24.2 install with GameData folder, so I am fortunate enough to simply continue my career in that version for now, but I know that this is not viable for the long term. At the same time, I am very well past the threshold where I could ever go back to Win32, even with the most aggressive of aggressive ATM settings. So, I shall now work toward installing Linux and using that OS's x64 build for a while. And that's where I need some help. I am very comfortable with operating system installs, partitioning and formatting hard drives, and tweaking config settings. I got my feet wet back in the days of MS-DOS 4.0, and they haven't dried off since. I custom-specked my current system and assembled it myself, so I am not normally intimidated by the prospect of performing any type of surgery on a computer, be that with a screwdriver or a keyboard. That said, I am a Linux (and Apple, incidentally) virgin. I understand that many of the principles are the same, and I know I can install dual-boot scenarios, but I would appreciate some KSP-specific advice. What distro should I download? Is running Linux through a Windows shell possible (as that would allow me to not worry about losing access to some of my work-related and school-related always-on software that I run in Win7)? What other questions should I be considering in preparing for this migration / expansion? Because it's relevant, my system specs are as follows: Windows Experience Rating: 7.3 (slightly bottlenecked from a 7.4 by primary hdd) Windows 7 Professional x64 (can upgrade to Win8.1 if necessary, but I would prefer not, as I actually manually downgraded back to Win7 for other reasons) AMD Phenom II X4 965 3.41GHz 16GB ram AMD RadeonHD 4895 (x3) on CrossFire 2.0 Primary 256GB SSD Secondary 1TB RAID+0 Velociraptor (x4) Display 1920x1200 primary, 1920x1080 secondary No onboard optical drive, but I do have an external available, plus ample USB flashdrives and HDD's available I keep a live cloud backup of all perishable data, so repartitioning, reformatting, and reinstalling Win7 to accommodate a dual install is easily justifiable and would likely only knock my system out of commission for a day while updates download and install. That said, I'd again prefer the ability to run Linux as a shell from within Win7 if possible, so as to maintain access to other Win7 programs while playing KSP. As I use MSE for my antimalware, running Steam and / or KSP64 from Linux as a hard boot would necessitate some form of antimalware solution, which again, is a duplication of effort that I'd care to try to avoid if doing so would not be too Rube Goldberg-ian. KSP64 is, at this point, the only durable reason to even consider this effort. Any thoughts would be welcome. Thanks.

I recall a time when I could view my own forum post activity further back than the system seems keyed to allow for now. Is it 24 hours that my posts remain visible within my history? 36? At any rate, how do I look at my previous post activity, or keep tabs on ongoing threads, without saving bookmarks to my browser? Am I doing something wrong? Thanks.

For the record, I've seen the anti-x64 movement from modders, not the least of whom ferram4, who have affirmatively withheld x64 support. Until I manage to install Linux (a process to which I do not look forward) I shall enjoy the fact that I archived my 0.24.2 install and segregated my mods. I am very well past the threshold where ATM could even possibly help me remain within x86 memory limits. Pity.

I think perhaps if it happened while the "KJR"-related note in the corner is loading during physics load, it would be easy to wonder if it were coincidence or not.

Yeah. Your dishes are useful as dishes because of their incredibly long range -- in your case, to Duna. The tradeoff for that range, however, is that all signals have to be within the dish's "line of sight," or cone in RT2. Your dishes being used for close-quarters comms is literally the same thing as you trying to use your telescope to read your computer screen. The line of sight, field of view, and resolution just wouldn't be appropriate. Make a series of networks within each individual SOI -- one for LKO, one for LMO / LMinO, and one for Extreme-KO, edge-of-SOI stuff. Make each network, individually, all-passive, with omnidirectional antennae, so that all you need to use that network is to be in range, with no dish targeting. Design a way to make those networks talk to each other with dishes. That would obviously entail placing dishes and omnis on the same satellites, of course, but don't target your dishes on anything within the same network (if you can maintain a reliable and stable connection passively, of course. if you must use a targeted dish, for example between dishes in your Edge-Kerbin-SOI network, then fine.) For example, your LKO satellites might have one dish targeted to the Mun, one to Minmus, one to your Edge-of-SOI, and one to "active vessel" as a safety measure. And one unused. Make sure you populate the LKO orbit with enough that you have universal coverage with omnis. Mun network: each has a dish pointed toward LKO, and one to active vessel. Edge: One pointed to LKO, one to Duna, one to active vessel, and two or three unused. A Duna-bound craft, then, would need an in-atmo passive; an Omni for once you get high enough to pop fairings if running FAR; a dish pointed at Kerbin itself; one or even two dishes to individual Edge-KO satellites; and one or two pointed at specific LKO satellites that are likely to be in line of sight well after your initial ejection burn, so that you can monitor it as it exits SOI and manually change relays as your altitude increases within the Kerbin SOI and maintain contact with a minimum of two other satellites; and if possible, 2 or 3 empty dishes. I know that seems overkillish, and you can shut down unused dishes to conserve power if need be, and if you're sending a probe to Duna, I always try to graveyard them into a sort of vanguard network at the destination once they're science-exhausted. A properly delivered and implemented Low-Duna network would be needed, as well as an Ike network, and an Edge-Duna network, and delivering those networks will be easier if you have even one still-transmitting probe already in orbit, or hell, even landed if it's intact. - - - Updated - - - Beyond that, I'm still willing to look at your savefile and .craft file. You mention in your photo album that you "set" something to be a root part. What exactly do you mean by that?

As for the clicking problem only beginning to happen recently... *shrug* I suggest that you were merely lucky to have avoided game-breaking symptoms. The info you link to above speaks of an out-of-memory crash. First of all, I'm no expert (and the experts here will be exceedingly frustrated by support requests that post partial info, see quoted link above) but I gather that your system is running low on memory. Whatever your total system memory is, know that a large chunk of it is used by the operating system itself, plus any antimalware you run and other background processes. Add to THAT the fact that KSP is a very memory-hungry application on its own merits, let alone adding to that footprint with mods. Mods, bear in mind, weigh very heavily on KSP's memory footprint. Generally, know that part-heavy mods (specifically, the texture files within them) are peculiarly consumptive of memory, though plugins (non-part, "behavior"-heavy mods, such as Blizzy's Toolbar, or MechJeb) are not memory-free. Worse, plugins can be very bursty in their memory consumption, and how much they use (or need, or forcefully take) can vary dramatically, particularly at gamescene transitions, I find. You list not only B9, arguably one of the part-heaviest (and by extension, memory-heaviest) mod on the forums, let alone EVE and Better Atmospheres (which, while part-empty mods, are literally NOTHING but textures -- large, high resolution textures, at that -- which is the problem-causing component of part-mods anyway). From the B9 host thread: Know also that x86 applications (32-bit) are, as a class of applications, universally limited to 4GB of memory at any given time. I don't care if you have a thousand gigs of memory, a 32-bit application is physically incapable of using any more than 4 gigs at a time, period. 64-bit programs are capable of using more than that (they have their own limit, but it's hundreds of times higher than just 4gb), but of course, the 64-bit program has to be well-designed to use that extra memory (and Unity-64, the programming environment that KSP is designed in, is very poorly designed to do this right now) hence your x64 issues. Note, running ATM and EVE/BA is possible, but takes some tweaking. Be sure to delete your cached texture files between test-runs after changing the settings to make sure that your testing yields reliable results. Once you get it working, DON'T delete your cached textures, however, because that's how it runs. Also, be advised that this may or may not help you. It's helped me with respect to some stability and OOM-crash issues, but my x64 clicking issues persist.

YouTuber Bob Fitch has documented and described numerous instances of RT2 problems being caused by un-kerballed craft being controllable or not based on what the actual root part is of the vessel. It's important that that the root part be the actual probe core that RT2 is supposed to interact with (I think.) Regardless, the SelectRoot mod is invaluable for fixing this in the VAB, if it is indeed your problem. This theory would be stronger if you CAN control the craft during launch, but it suddenly becomes uncontrollable after the last staging event, possibly during or after your ejection burn. Since you say here that your craft becomes uncontrollable while still I Kerbin SOI, I suspect it may be involved. Again, detailed screencaps, and careful and thorough description of your method (heck, PM me and I'll take a look at your .craft file) may confirm or debunk this possible explanation.

From (the B9 host thread)

It may be the case that warping through any SOI change, of any craft, anywhere in the save, can have deleterious effects on any other orbit in the save. If so, then it would therefore be irrelevant that the craft in question experienced no SOI changes during your warp period. Your steps taken, by your description, seem to account for this however.

Perhaps some screencaps would be helpful here. You mention that your relay satellite is in a polar orbit, but line of sight is not an issue? Perhaps try putting multiple satellites in that polar orbit, spaced the same as your keosynch array (same altitude and number.) Then, target all of those polar relays to your probe, and target your probe toward Kerbin with a closer-range antenna instead of the primary antenna designed to work out at Duna.

Your question was already explicitly answered. There does not exist any known solution to this. This has nothing to do with your mods or your computer. This is a bug that has been known in x64 for a long time, and it is hard-coded if not into KSP itself then in Unity-64 (the environment in which KSP-64 is programmed.) It's not sudden, it's not something you did, and for the moment, there's nothing that you as the end-user can do about it. Other than quicksaving your game and be willing to periodically exit to the Space Center screen (which is how the game "slowsaves" to the persistence file, as distinguished from quicksaving) and perhaps even exiting and restarting KSP itself...

First of all, why the haterade on FAR? I have always considered it a must-have mod, as to several YouTubers. I'm not judging, I'm legit curious what the opposing view is. And with respect to biomes, I won't deny that this IS cool, but I've been using CustomBiomes at http://forum.kerbalspaceprogram.com/threads/66256-0-24-2-Custom-Biomes-1-6-5-27-Jul for a while now. That said, I do admit that there's not much need to expand beyond Kerbin/Mun/Minmus right now, unless you play a modded tech tree (BTSM, KSPI, etc.)

Prolly with HyperEdit, since I don't see a drive system in the flybys. Else, infinifuel. And the launcher was hardcore KW, with IR for the extension antenna. Possibly others.

Video that. de-orbiting a space station is sure to either generate a incredible Manley-esq feet of skill or a Danny-esq feet of hilarious destruction. Hmm. I may do just that. I'm new to vidcap and editing, however. I downloaded Camtasia, which seems intuitive enough from the editing side, but I'm having trouble recording anything other than the desktop BEHIND the game. Yes, I know you can run KSP in windowed mode, and I might do that for now. Bandicam seems like it's better on the recording side, but on editing it's crap. Any other suggestions?

Could that issue have anything to do with kerbal placement? In other words, do the correct numbers of kerbonauts need to actually be in the individual lab modules for them to work? Or is it an ALL_VESSEL type thing, where as long as you have enough kerbals somewhere, cumulatively, it'll work?

Well, for something as intrinsic to the behavior of the contract (and I am not arguing that the mechanic itself doesn't make sense -- it makes perfect sense, now that I realize it) a full disclosure seems appropriate. And some of the flavor-text on other parts and contracts is pretty substantial in its own right. That, and I don't think this is too substantial, now that you mention that you're awaiting 0.25 for the staging fix. Part text: "This module can of course be permanently attached to a station or non-Kerbin base for ongoing Science gains, if its prerequisite accoutrements are also provided. That said, most contracts involving this piece call for new modules to be custom-launched and manually landed back at Kerbin for retrieval in order to discharge them -- be sure to pay keen attention to the exat details-text of the contract for further guidance. This is because MisterFister Laboratories advises us that sometimes we just cannot trust the reported observations of snack-addled kerbonauts in orbit, even if they manually extract the findings-payload from this pod and return it that way so as to continue reusing the pod for future contracts or ongoing research; the actual module-pod itself is needed by the contract sponsor back on Kerbin in order to confirm findings for certain types of research projects." Contract text: "We here at StrutCo, in partnership with MisterFister Laboratories and Your Mom's Emporium of Mint-Toothpaste-Orange-Juice-and-Bubblegum Flavoring Additives, are advised that for this contract to work, a new test module must be custom launched and subsequently landed back at Kerbin for retrieval to trigger final contract completion. This is because, while we salute our fine stalwart kerbonauts on their attention to detail and upright professionalism, returning the results separately from retrieving the experiment module just won't cut it. Sorry, Snackfried and Roy, but you're just gonna have to do this the hard way. (Supporting structures necessary for this pod's operation need not be custom launched for this contract, however.)" Meh. Maybe. I hope you can find something useful in this, at any rate. I'm not wedded to it, and your mod is otherwise an awesome must-install for me.

Meh. First off, the mistake was mine... though, I can imagine others making the same one. Perhaps my confusion is borne not just from the contract text but also from the part description in the VAB. If the VAB / SPH part text could read something along the lines of, for the test module, "This module can of course be permanently attached to a station or non-Kerbin base for ongoing Science gains, if its prerequisite accoutrements are also provided. That said, most contracts involving this piece call for new modules to be custom-launched and manually landed back at Kerbin for retrieval in order to discharge them -- be sure to pay keen attention to the exat details-text of the contract for further guidance. This is because MisterFister Laboratories advises us that sometimes we just cannot trust the reported observations of snack-addled kerbonauts in orbit, even if they manually extract the findings-payload from this pod and return it that way so as to continue reusing the pod for future contracts or ongoing research; the actual module-pod itself is needed by the contract sponsor back on Kerbin in order to confirm findings for certain types of research projects. NOTE: When launching these modules for contracts, be sure to use the staging function to activate your initial launch stage, INSTEAD of right-clicking or action-group-toggling the launch engines. It is the STAGE function that triggers completion of the "launch new module" component of a Station Science contract and not mere delivery of the payload to the destination SOI-context." For the contract text: "We here at StrutCo, in partnership with MisterFister Laboratories and Your Mom's Emporium of Mint-Toothpaste-Orange-Juice-and-Bubblegum Flavoring Additives, are advised that for this contract to work, a new test module must be custom launched and subsequently landed back at Kerbin for retrieval to trigger final contract completion. This is because, while we salute our fine stalwart kerbonauts on their attention to detail and upright professionalism, returning the results separately from retrieving the experiment module just won't cut it. Sorry, Snackfried and Roy, but you're just gonna have to do this the hard way. (Supporting structures necessary for this pod's operation need not be custom launched for this contract, however.) NOTE: When launching these modules for contracts, be sure to use the staging function to activate your initial launch stage, INSTEAD of right-clicking or action-group-toggling the launch engines. It is the STAGE function that triggers completion of the "launch new module" component of a Station Science contract and not mere delivery of the payload to the destination SOI-context."

Well I wish I'd known that before I got greedy and decided to attempt the mission, with more than a year left in the contract term, without first unlocking docking ports. (I use Kerbal Construction Time too, which means I have to plan my launches and my tech unlocks rather carefully against my contract assignments.) Well, time to bring up some KAS-attachable parachutes on the retrieval rig! This beast is gonna get WARM!

I have two overlapping contracts for these, one for Plant Growth and one for Creature Comforts. Now, I'm pretty early in my tech tree, and I'm fairly certain that this ungainly space-noodle will incinerate on reentry. (Add to that the fact that I forgot to send up a zoology bay, like a nimrod.) I'd planned on sending a retrieval craft anyway, and it's no big deal to include a zoology bay with it. My question: the contract stipulates that I have to "recover it" on Kerbin. Does that mean that bringing the experiment data won't be enough, I actually have to recover the module itself?

Is there any way to load in a personal music collection and jukebox it through randomly? As in, from an iTunes account, Pandora, or other somesuch? I like the idea of transitioning between iPod playlists based on gamescene, but also the option to either save the progress in any given playlist or to shuffle each one individually without mixing them. Is this just way out of scope for this mod?

Thanks! Downloading now -- though, KerbalStuff itself seems to be on the fritz.

While I suppose that this might be helpful to some, it is very important to know that the x64 instability issues are not video card related, not mod related, and not KSP related. They are related to bugs in Unity-64, the game engine BEHIND KSP's 64-bit version. (Also know that desktop graphics cards, beyond "power profiles" you suggest that Windows might indeed be able to access on a desktop, are extremely UNFRIENDLY to changing "voltages." While clock speeds and "overclocking" are possibilities, messing with video card voltages directly is a good way to destroy the equipment.) You may want to check out http://forum.kerbalspaceprogram.com/threads/94086-x64-works-%21-But-I-don-t-know-why%21-Please-help-me-replicate, http://forum.kerbalspaceprogram.com/threads/92229-How-To-Get-Support-(READ-FIRST), and other threads for further information.