StarkRG

Not sure if this has been discussed before (did a thread search but I don't have a good history with those things), is there any chance of getting support for Blizzy's toolbar? I like having the option to disable buttons I.don't need and Blizzy's method of dealing with more buttons (display them in rows) is way better than stock's (annoying and slow buttons to scroll through them).

And by "slows to a crawl" I mean about one frame, or less, per minute (with brief spurts of about 1-2 fps). It actually seems to speed up a little (but not by much) if I.let go of the ship and move around with suit thrusters (which is rather dangerous when operating at extremely low fps).. I've got a lot of mods so it'll take a long time to compile a list of what mods I've got installed (but can if you really want me to). The important ones to this situation are KAS and Orbital Material Science and the part in question is the KEES Passive Experiment Carrier. The problem goes away, however, if I manage to get back inside and then EVA again. Basically it feels like it's going into a processing loop. What's causing these hangups? What, if anything, can I.do to relieve this issue?

My computing experience began with Mac, then moved to Linux, and it's only been the last four or five years that I've been using Windows. I've always thought Windows crash logs left much to be desired. On the one hand they're completely incomprehensible, using hex error IDs that I'd have to go look up somewhere to even know what the crash WAS, let alone why it happened. And yet, on the other hand, they provide so little information on what actually caused the issue that even if I knew what the crash was I'm unlikely to ever find out why, and, therefore, have any chance of stopping it from happening in the future. I end up doing what I imagine most plebs do and pray that the error boogeyman doesn't return. I haven't played KSP on anything but Windows so I'm not sure if the error logs are any more insightful on other platforms, all I know is they mean very little to me. My most recent crash shows up as "mono.dll caused an Access Violation (0xc0000005) in module mono.dll at 0023:10118f0a." Which is a stupid thing to say, because of course it caused an error in itself, it certainly didn't cause a bank error in my favor (is it common for DLLs to cause errors in other DLLs? That would seem to be rather problematic from a security standpoint). I assume that hex number is the ID code of the error (How many errors do they have coded that they need a 64-bit number to designate them all? Actually, I can tell you, judging by the c (1100), it's at least 18 quintillion), I'm glad they've finally started to give us the name of the error in addition to the ID, I'd hate to have to flip through what must be a gigantic manual consisting of several hundred trillion pages to look it up. I don't know where "0023:10118f0a" is, that might make some bit of sense if I had the code in front of me, though I kinda doubt it, but otherwise it's meaningless gibberish. Based on what little programming experience I have, I'm assuming that "access violation" means "buffer overflow" due to running out of memory. There's a section for "Context" which provides no context whatsoever, it's clearly using an extremely obscure definition of the word. Similarly "Bytes at CS:EIP" appears to be of very little help. As is, for that matter, the stack, which appears to be a dump of some section of memory, presumably the stack, with no readily apparent structure, basically just the apparently random noise you get with arbitrary memory dumps (like uninitialized arrays). This is followed by an apparently arbitrary subset of the DLLs, I can only assume, the game had loaded, it's not all of them that must be loaded (since none of the addons are in there), but they also seem to be related to the game in some way (like xinput and that damnable mono.dll, which might as well be aids.dll, though in this context I imagine it's referring to the software compatibility platform rather than the viral disease). Say what you will about Java (and I agree, it's a godawful language and platform that, in trying to be good at everything, has ended up not really been being good for anything) at least when it crashes, which it does often and with great enthusiasm, its error messages are somewhat understandable and helpful in avoiding similar errors in the future.

You absolutely CAN control unkerbed probes. I just looked up the specifics and it's actually 6 kerbals and a large probe core (RC-L01 Remote Guidance Unit). As for keeping them alive indefinitely. It's true that permanence is impossible, but the time can be extended to insane amounts (and, besides, you'll be warned before it becomes a real issue). Include a bunch of life support, and recycling systems. That's all assuming you're not playing on career where funds are an issue (unless you cheat in the funds to get it set up, which, if there was no other option, I, personally, wouldn't have a problem doing). In any case the above patch sounds like your best bet.

Of course, using omnis in this way is rather silly since you'd need many more satellites than you would just using dishes. With dishes you just need 3 satellites and they don't need one dedicated to KSC, just point them at Kerbin and you'll pick up both KSC and Communotron omnis. The DTS-M1 is nice in that it gives you a 45 degree angle when pointed at Kerbin, this is enough to get most low-kerbin and medium-kerbin orbits (above a certain height you'll get drop-outs as you pass out of the angle).

Oh, of course you're right, for some reason I read the range as 4.5Mm instead of 2.5. Scratch that, no he's not, #3 is 2.4Mm away from #2 which is 2.4Mm from #1, they should be relaying.

I'm not familiar with V.F.M Fuel Panel, how does it differ from TAC? From what I've gathered by a quick glance TAC seems to do everything that VFM did.

Sure, but at the same time, the best way to learn how and eventually get used to it is to fail often. Avoiding it isn't going to make things easier.

I've got a suggestion for an alternative name for the "kelio-" prefix, that is "kebo-" (pronounced KEE-bo). I like this a bit better than "kelio-", I love that the mod's config files allows me to change this for myself, but I figured I'd tell other people about my idea.

Hmm, see I tend to go lower the higher my entry speed. My thinking behind this is that if I'm too high I won't slow down in time and I'll end up having to go around again (and depending on how I've rationed my life support and electricity supplies that might end up killing my kerbals). More velocity means more that needs to bleed off in order to return. FAR/NEAR atmospheres are pretty damn thin down to around 20km. Dropping down from Minmus I tend to dip to somewhere around 28km-30km. I haven't returned from interplanetary speeds yet, but I figure one pass at around 35km-40km for capture should put me on the ground during the second pass. Nonsense. I've returned direct from Minmus easy. Takes a little getting used to, I'll grant you, but it's not as difficult as it first seems. I found 35 requires another go around while 25 kills you, I think 28 might be the sweet spot. Granted I tend to do this thanks to using TAC life support and reducing the amount of stuff I bring along to a minimum. I tend to not bring my solar panels back with me unless I can help it which means if I need another go around I'll likely run out of power before I get back, this might mean my kerbals die from lack of electricity or, more likely, it'll mean I can't orient my capsule properly. It's a risk, but in career every little bit of money you can return counts (depending on how hard up you are), and some of those experiments aren't cheap.

Yeah, this would necessitate a fairly large change to the way KSP itself handles save files. I don't think it should necessarily (depending on how it was implemented) cause too much of an increase in loading time since the system has to look for the part config while loading the craft anyway, this would simply bypass that. Of course, parts are pre-loaded at start-up so there's less searching and loading required, however if the part was included higher up in the save file hierarchy rather than embedded in the vessels themselves they could be pre-loaded along with the rest of the save-file. Of course, the issue then, is that, instead of having part files that you can simply delete you have them embedded in the save file which would either have to be edited by hand or additional code included to allow for their deletion in-game. It's a nice idea, but I think efforts are better spent elsewhere at the moment.

If you force a connection from #2 to #1 (you'd have to have dishes point at each other), is the connection active? I've never tried to use omnis for relaying, only for the last leg of the connection.

So I've got a bunch of mods installed (as do most of us I think), and not all of them work well together (some capsules don't have heat shields but should, some probe cores can be controlled without a remote tech connection, etc.). Originally I was just going to edit the part files themselves, but then I realized that I'd have to re-edit them every time I updated, thus I started looking into MM configs. I looked around for some pre-made ones but couldn't find any so I've thrown together a few and figured someone else might be in the position I was in and want some configs without the hassle of making them themselves. To that end, I've uploaded them for people to download. They're really very basic hack jobs, mostly just copy-pasta with a tiny effort put into balance. Obviously I only have the stuff I use in there, and I've been collecting them as I discover things that aren't implemented so there's a whole lot that aren't included. Given their ad-hoc nature, I'd be happy for some input with regards to balance (does the amount of ablative shielding make sense given the probe's mass and size? Does the antenna's range make sense given its cost, design, and original purpose?) and things I've missed. If nobody's interested, no loss to me, I want them and that's what I really care about.

Should be easy enough to create a stationary remote command station (I think it's the large probe core and 7 kerbals). You wouldn't be able to transmit science (you'd need a connection to the KSC to do that) but you could still control unkerbaled probes.

Well now I think we need an addition to this mod, a blender attachment to get even more science. Doesn't just have to be limited to this mod. Take the science out of a part that uses physical material (goo, materials bay, banana, soil sample), place it in the blender to add to the science. Maybe even add multiple sciences for even more science (what happens if you blend the goo and a Minmus soil sample while orbiting Ike? Could be a percentage increase, or just additive. If it was percentage you could even lose science under certain conditions (banana from Moho and materials from the Mun loses 10% of the combined science). Or if you mixed incompatible samples together something could happen (goo from Eve mixed with materials from Jool while on the surface of Dres causes an explosion which destroys the blender and all the science, or mixing a banana with Minmus soil and tasting it while flying through Jool's atmosphere teleports the kerbal to an arbitrary location, maybe a munar arch).

I don't think I am, really. I'm not suggesting it would be easy by any means. The densities of nebulae are less than the density of the lunar atmosphere. To put it another way, the most perfect artificial vacuum we can create on Earth is far more dense than your average nebula. So no, there wouldn't be an atmosphere. Basically what I'm suggesting is creating a very large object that has absolutely no substance, just a texture. Additionally I'd look at using the Environmental Visual Enhancements mod to add volumetric "clouds", however I'd have to find out if there's a way to have them fade out as you get closer to them. There is virtually no visual difference between being inside a nebula and not, the only reason we can see them is that they're so massively gigantic, even so you generally can't even see most of them with your standard backyard telescope (in fact, I'd be surprised if you could see any but the brightest without near-professional equipment with long exposures). As far as the stellar nursery goes it'd just be a collection of tiny stars in weird orbits. The protoplanetary disks would be troublesome, but might be done using EVE clouds, purely a visual thing, and a small handful of large asteroids (like Pol, Bop, and Gilly, something Ike-sized would be questionable) that may eventually become planets. I'll definitely look into what it'll take to do it. It's too bad that Oven disappeared. I've never done any KSP modding, but I do have some programming experience so I'll see whether the code makes any sense to me. If it does I might be able to take over, with your (and/or Oven's, if he does return and doesn't want to continue) permission, of course. I think this mod is important as it gives late-game goals which KSP doesn't really have at the moment (Eeloo and Tylo being the only real candidates).

Don't want to step on any of the devs' toes here, but I'd like to voice my opinion and agree with tychochallenge. This mod is essentially simulating a micro-galaxy, so the distances and orbital periods should be somewhat realistic (albeit kerbalish realism, krealism? realistik?). Distances measured in light-years or parsecs (even if it's fractional like tychochallenge suggested), SOIs on par with a kerbalized (ie. scaled down) heliopause (kerbopause?) several hundred Gm or single digit Tm (heliopause is about 18 Tm), and orbital periods measured in centuries (100 years at least, preferably quite a bit more). Perhaps in the future you could provide a config for those of us who want a larger system. That's all assuming Unity can handle those distances and doesn't just explode in a shower of kuarks and kluons (see what I did there?). It'd also be cool to see someone (possibly myself) work on creating a nebula-like object (extremely large gas-giant- or star-based object with extremely low density and, therefore, gravity, can only be seen from a distance, maybe utilizing volumetric clouds if they can be set up to become invisible when close by), possibly even with a stellar nursery). The SoI would have to be comparatively immense (certainly larger than a normal star system's), I'm thinking in the tens of Tm (tens of billions of km). Any stars inside would be bright and hot, with SoIs barely larger than a large gas giant, eccentric and randomly-inclined orbits (no ecliptic to speak of, not even any general agreement on direction, but because of the low gravity differences in orbital velocity would be relatively small), orbital periods of many centuries (millennia even, due to the low gravitational binding of the system), and possibly protoplanetary disks (volumetric-cloud-based dust rings with small asteroid objects, certainly nothing larger than pol). And finally, because I had to remove this mod due to these bugs, any chance of fixing the somewhat-random (though generally upwards) forces at launch and inadvertently launching from some, seemingly random (but probably isn't) height bugs?.

This looks really cool. I worry, though, about how (ie. whether) it'll work with DarkMultiPlayer (which even seems to have difficulty with the stock "revert to..." functions). I realize that getting this to play nice with DMP as it is now is nigh impossible, so I guess what I'd like to suggest is if SIT89 and godarklight could work together to get the two mods to interact peacefully. Chances are that getting DMP to work with something like this will iron out some of the remaining problems and instability with DMP.

What can be done about it? Additionally what would be necessary to convert an existing save to the new system if I want to add it after the fact (as in when the problem is solved)? Would everything fit into place as is or would I have to go through and change all the vessels' reference bodies by hand?

I'm building a rather large modpack for a private server and I've got a strange bug that only occurs when this mod is installed. During the first launch, just before physics begins, the ship (and launch clamps if you have them) is teleported to a high altitude (the height appears to be dependent on the length of the rocket, but it's hard to say for sure, what is for sure is that it's not always the same height). In normal single player it only happens the first time you launch, after that the launches work fine (ie. the un-bugginess is saved somehow in the save file). However with DMP (DarkMultiPlayer) it happens the first time you launch after every time you start the game (ie. the un-bugginess ISN'T saved). If it were just the first launch I'd say it's playable and keep it in the pack, as it stands, though, I'm going to have to leave it out (unless it can be solved quickish). I'm guessing it's got to be interacting with one of the other mods but my method for determining which mod caused the problem (disable half the mods, replace half until the problem returns, remove half the ones most recently added, etc) didn't allow me to find that out. I can certainly do more testing if someone can give me an idea of which ones to look at since it's such a huge list and none of them really seem like they'd be the culprit (I did test removing joint reinforcement, deadly re-entry, and NEAR, but it still occurred, in fact it was worse as the ship disintegrated on physics load instead of just teleporting) The mods in the pack: Aligned Currency Indicator AutoAsparagus Aviation Lights B9 Aerospace BananaForScale Ambient Light Adjustment Environmental Visual Enhancements CactEye Orbital Telescope Coherent Contracts Deadly Reentry RCS Build Aid RCS Landing Aid Action Groups Extended DMagic Orbital Science Enhanced Navball Fine Print Klockheed-Martian CoolRockets Klockheed-Martian Special Parts Version Checker Plugin Magic Smoke Industries Parts & Infernal Robotics MechJeb2 Mission Controller Extended Cargo Transportation Solutions Radially Attached Experimental Data Storage Container Spherical and Toridal Tank Pack Modular Fuel Tanks HotRockets NanoGauges Kethane Firespitter (full mod, not just dll) PartCatalog Solar Panel Wings Docking Port Alignment Indicator NEAR Final Frontier Notes 6S Service Compartment Tubes Kerbinium Asteroid Mining Part Angle Display Procedural Fairings Proximity alarm RCS Sound Effects RealChute RemoteTech 2 SCANsat ScienceAlert Mk2 Cockpit Internals SmokeScreen Spaceplane Plus Speedy's Hex Truss System StageRecovery Multiple Star Systems Station Science Surface Lights TAC Life Support TAC Fuel Balancer Time Control Kerbal Alarm Clock UAL002's Lorefriendy Serious Parody Flags Vanguard EVA parachutes KSP Interstellar Deployable Airbags Deployable Emergency Reentry Pod Asteroidal Resources kOS Scriptable Autopilot System Contract Manager NovaPunch Munar Rover Wheel Bahamuto Dynamics Retracting/vectoring engines Universal Storage Editor Extensions AerojetKerbodyne Texture Replacer

I'm positive that it wasn't an ad but was something mediafire was serving (it even redirected me to a separate error URL), it doesn't seem to be having the issue anymore though, so it must have just been a mediafire glitch.

"The file you requested has been blocked for a violation of our Terms of Service."

This looks great! I really want to use it, unfortunately, because I have AIES, toroidal/spherical tanks, B9, and KW installed, getting it set up for all those extra tanks will be quite a chore. Is it possible to have the plugin add this functionality to all tanks without needing a module manager config for each of them?

A bit annoying that the central tank apparently needs to be the root part. I've built the ship from the pod down (guess I'm having trouble getting used to the newfangled "anything can be root" idea), I attached decouplers in 6x symmetry, and then added tanks in 6x symmetry but it still refuses to place any fuel lines. If I build from the bottom up it works fine. Unfortunately that just isn't how I build things, I tend to create the payload and then guestimate what I need to lift it (none of these Manley-style, pen-and-paper calculations for me, that sounds like work).

Kinda cool that the outside of the VAB is textured, though it would be nice to see it properly modeled and textured like it is during simulation. The SPH, however, doesn't appear to be textured on the outside.