GavinZac

I sent a 'prospector' drill bot to The Mun with a KAS port, and when it worked, sent a Big Half-Spherical Tank from Talisar. Now that I look at it, my converter is on the liquid/oxy tank, but it definitely works for Xenon. I'm not sure what this indicates. I haven't tried putting a Connector Port straight on the converter. Sorry.

Downloading this just for the 'lean'. Is it possible to create a bigger one, as in, longer, so that it can form a ring around something in the middle? Like... (/ = lean, [] = hub cube, | - = straight parts) ..../.[].\ .../..|...\ .[]--[]--[] ...\..|.../ ....\.[]./

It would be great if this worked. I'm pretty uncomfortable hard-editing all of Squad's parts.

It seems to work fine - it fills up empty tanks regardless of which side of the KAS they are on, so long as it is connected in 'docked' mode.

Design idea: point the drill forward, and put (folded) landing legs on the top of the rover. Tip the rover forward onto the drill and landing legs; when done, unfold the landing leg(s) to push the rover back down. Or, stick it on a Damned Robotics hinge, no tipping needed.

If you don't know, wait for someone else to do it.

You haven't been following the thread? You post almost daily whining about a minor issue that only affects people with certain resolutions. At one point you accused them of *intending* to mess things up, presumably just for you since it isn't happening on most people's machines and presumably isnt happening on the dev's.

Has there been any fix/indication of the cause of the rendezvous auto-pilot being terrible? I launch to rendezvous in the right orbital plane and altitude. I get into space maybe 0.5 degrees out. I switch to rendezvous autopilot. Rendezvous autopilot spends a half hour trying to match planes with the target. When it does, the target is now long gone. It sets up a climb to transfer 100km->215km->100km. It gets an intercept - and then starts lagging like crazy. It says it will start match velocities with the target... in 68 years, 68 days... I disable that, and let the crafts come closer together. Then I reengage autopilot, and it needs to make more adjustments. At this point, I've nearly doubled the Delta-V I had planned to spend in space. Often, the readjustments are too much, and it starts swinging like crazy trying to get a perfect target approach - and the result is that it slams through the target like a battering ram. Reload quicksave. Rinse and repeat.

Well, how Kethane does it (and, er, how mine does it, if it stops crashing the game) is only ever show the map of the body you're around. It's a design choice but I think at this point it's evident that having all the maps loaded for immediate viewing, and having very high resolution, may be mutually exclusive for some people's machines. Well, mods definitely affect the memory, in ways that are not immediate. It really does seem as if, for example, putting a craft with a scanner on the launchpad loads up those images, given the difference in RAM usage with and without the scanner. I can't say for certain as while I'm familiar with C#, this is my first time messing with Unity. Second, if you count downloading it, installing it and failing miserably at making a model a few months ago. I fear this is heading into "Add-on development" territory so we'll leave it there.

I'm currently currently messing around with a mod-mod of ISA MapSat, and I can confirm that the full, extra-large images for every body are being loaded right at the start, rather than, say, at sphere of influence change. I'm not sure if there's on "onSphereOfInfluenceChange()" function but if there is, it doesnt seem like it would be difficult to do the loading (and unloading!) then. My mod-mod actually does something like this but, because it's now loaded the image twice, it is crashing on my system. I guess I should make a clean install for testing!

Would it be possible to 'tag' the assemblies instead? If the plugin saved a commented line in a specific format with comma-delineated tags in it, it should affect the game, and it would be useful to have items in several categories, e.g.: [*] launcher,heavy,stock [*] unmanned,satellite,ISAMapSat This would also solve the category deletion problem - you'd simply be removing a tag rather than dealing with deleting folders and moving files.

That didn't work for me, but I found something that does: looking "down" the corridor and placing the airlock at the other (far) end.

Yes, but for me, it's sticking to the inner walls of the corridor, or the rim of the 'doorframe'.

I'm quite excited for this; I'm constantly snapping screenshots but I play in low settings to keep my FPS up. I'm wondering how it will interact with Steam's screenshot system - is it possible for something like this to 'prepare' for a screenshot and then actually take it with Steam £

No, he means that someone (two people, coincidentally) fixed the code already and released a fixed version (a fork, called Infernal Robotics). DYJ's salient point is that that fork shouldn't be distributing his models without his permission - the models and the plugin have different licenses. Of course, the GPL states that any derivative work must also be GPL (free as in speech, to distribute and change), there is no reason that Damned Robotics can't just merge in the fix from 'infernal' Robotics. This is why GPL is a Good Thing - we'd all have been doing great if the person who patched this had simply distributed mumech.dll and not the whole package - it would have been a simple copy-paste-overwrite.

Win64 runs Win32 programs in a compatibility mode - limiting the program to the amount of memory the program would expect to be available.

I think I'm missing something obvious, but how on earth (Kerbin?) do I get the MMM Airlock to attach to the end of a corridor? The Vertical Airlock attaches, but doesn't look pretty (I don't know what the functional difference is, I'm just looking around)

Unfortunately, for me, it doesn't really react to moving around by WASD, and if I enable RCS it shudders too much to see the planets clearly (they are certainly there). What am I doing wrong?

Yeah, I can confirm that. One of the little cubes on the end, or better, a truss part from one of the many 'structural truss' mods works well.

It's a limitation of the game. Because it's a one-player, enjoy-it-how-you-like-it game, there's nothing stopping you from just popping a fully scanned map into the folder and using that, if it annoys you that much.

The GitHub link above works fine, although I havent used the claw yet.

To explain further, every mod will have its own folder in GameData, so GameData could end up looking like MechJeb Telemachus Chatterer Squad With Squad's own core files loaded as if they were a mod. This means that there should be no risk of corrupting the stock parts. If you are paranoid like me, you can also zip up the Squad folder so that you have a backup. You can leave it in this folder as .zip files arent read by the game.

Has anyone installed Multiwheels with the new GPL bug fixed version of mumech.dll, to see if those Damned Robotics errors go away?

I live in Malaysia, currently on holidays on Pulau Perhentian Kecil. Trying to concentrate on seeing reef sharks today instead of theorising whether I can make a docking ring rotate with servos.

That is step by step. Beginning of steps: Step 1: Unzip the file so that it looks like that. End of steps.