Tallinu

This mod sounds interesting and the pictures with all the different colored lines look neat, but I don't know if I'm understanding everything properly. It sounds like the changes it makes act purely as restrictions, disallowing a vessel which is assigned to one frequency from using any relays that are not on the same frequency. Does doing this have some kind of gameplay benefit over the stock behavior of automatically finding the relay(s) that get the best signal strength? (Or does stock NOT always get the best signal strength?) Is there some actual benefit to having multiple different sets of relays on different channels, and having different vessels use those different relay networks? Does this mod somehow make it necessary to do that, reward you for doing it, or penalize you in some way if you just leave all your ships set to the same channel?Because it sounds like the only reward for spending more time and money putting up those extra satellites is to have really cool looking comm-net diagrams. To put it another way, I'm not sure if this this is intended for realistic gameplay / difficulty increase purposes, or cosmetic / "cool factor" purposes. I'm sure the new RemoteTech is going to be the former, of course, but for this mod I'm not certain if it's the latter or if I've missed something.

Thanks, now it seems to work just fine, so far!

Taniwha, that would be very much appreciated. I've been using "allow unrestricted transfers" rather than just uninstalling since I wanted to make sure I was still building out of parts that were passable, for when it was working properly again. I didn't know you could force it to update by exiting and re-boarding though. Thanks for pointing that out, Tonka! Actually, I can't get that to work. However, the next time any changes are made like docking/undocking or decoupling, that seems to force an update to whatever was already connected. For instance, on this test rig I made while trying to work out the details of the bug so I could report it (which turned out to be unnecessary), it starts with a command pod, two docking ports coupled together, and another crewed part with a third docking port on top. Then there's a framework going up to a decoupler holding another capsule with a docking port just above it, so that when decoupled, the slight fall brings the two unmated ports together. If I close the hatches which start out coupled together before firing the decoupler, the result is three separate living spaces. Boarding and exiting any of the pods doesn't seem to do anything. But then if I decouple the ports that start out attached (after opening both hatches on the newly docked parts), then the two sections still attached to each other finally merge into one space. Still easier to just use the unrestricted transfers option for now though.

The new version of these are absolutely gorgeous, especially with the clean insulated mounting border options! The only thing I've been disappointed by so far is that the multi-way hub piece can't be tweakscaled down to 1.25m for use with all the 1.25m parts and crew tubes... (After watching Kottobos' spotlight, I saw that there is a 1.25m version of it, which apparently I've somehow failed to unlock in the career game I'm playing despite unlocking the 2.5m version. Weird!) Also, I'm a little confused by the presence of flight control props in the IVA of the Porthole. It makes a great 1.25m endcap or nosecone, and the throttle and joystick on the kerbal's seat makes me think I should be able to find a way to "control from here" (like you can with docking ports, even though they aren't command pods) so that I could fly while looking out its lovely IVA windows. I wonder if there's some way to make it usable as such (like the larger, but terribly unaerodynamic, 2.5m cupola pod), without necessarily adding all the other bells and whistles a full command pod generally comes with? Maybe the module used by the external command seat, if it's different from what the normal command pods use?

Awesome! Really glad to see this updated (even if the old version might technically work).

Ah, that portion has the right link too, okay. At any rate, having now read that tutorial, it seems relatively straightforward (although a slightly non-trivial flight plan, at least for that particular vehicle design). Of course, that said, I still haven't managed to build a spaceplane that can actually do anything useful! XD (Was trying desperately to make one for simple orbital tourism or crew transport that could be used with mid-game tech earlier in the year, but couldn't even get something that simple to reach space reliably...)

These links (in the first post as well as the quoted post on page 39) both just direct me back to the first post of this thread. Does anyone know where this tutorial is actually located? Edit: Argh, it's actually just some annoying forum usability BS. It turns out that the little tiny diagonal arrow graphic in the very upper left corner that I didn't even notice until after looking at the dang thing a dozen times and carefully mousing over every bit of it, hunting for something that gave a different URL tooltip... anyway, that little arrow is actually the link to the post containing the tutorial, while the big header line below which LOOKS like what you're supposed to click on is just telling you what thread it was posted to... and directing you to its first post, as if that big bold link to the first post was more important than the post you're actually trying to reach.

@Drew Kerman Yeah, it no longer does that in the latest version. (Yay!)

Sounds great! Thanks.

As in, control-clicking a different part, or picking up a different part? I tried grabbing new parts out of the list on the left too, but that wasn't working. Only parts that were already on the vessel would clear it when clicked or alt-clicked to pick them up. Anyway, thanks for the update! This master snap mode is definitely a big help with positioning multiple asparagus stages or SRBs where the decoupler has to be moved vertically to get the ejection force to tilt the booster away safely, but the correct position isn't near the middle of a part. On a previous topic, alt-C works for going directly to the no angle snap setting, but it doesn't toggle it back to the previous setting when pressed again (so I have to hit C several times). Any chance of making it behave the same way that clicking on it with the mouse does, where it goes to no-snap with one click and then back to the previous angle setting if clicked again?

The only thing I've found which actually disables master snap mode (and the associated glow with the part tooltip stuck to your mouse pointer that the glow causes) is to pick up a part off of my vessel, although I can do so while holding down ALT to copy instead of remove parts and then trash the extras. Clicking on the interior of the VAB in the background does nothing (even if holding down control). That's what I would imagine "clicking an empty space" means, but maybe I'm wrong? I have a few other mods installed, so maybe one of them is interfering somehow. Here's my KSP.log: https://dl.dropboxusercontent.com/u/203721/KSP.log

@Fwiffo I wasn't aware of that one. I'll try it, thanks. The multiple axis thing only seems to happen when using translate with a part that isn't on a snap point for the other axes, but it's hard to tell under what conditions that's true... and I have yet to find a situation in which translation snap points have been remotely useful anyway (or even consistent between different parts attached to the same parent). Oh, and I just remembered the other thing that always annoys me: When you've clicked in the ship title, description, or the parts search fields and are typing, EEX still reads the keys you press and does things like reset your camera position, toggle options on and off, (trivially) change symmetry options, or (not so trivially) accidentally reposition parts, and so on. I've even had it reposition a large chunk of a subassembly I was saving while I was entering its name ("Drive Module", entering the V caused a large surface-attached part to shift way out of position, even while the assembly was still held by the mouse pointer). After typing anything more than a short word or two where I manage to see which options get flipped before another notice appears in its place, I have to refer to the key bindings (so I don't forget any) and toggle them all to check and/or reset their state.

Well, I've discovered that FS does not play well with attempting to store multiple copies of experiments. For an easy example, right click on a science box and use the option which makes it collect data out of other parts. FS immediately re-runs all experiments (because they are no longer present in its preferred command module), and then starts grabbing experiment data out of every other part on the ship, including the science storage compartment you just moved the previous results into, resulting in a whole bunch of duplicates being created and discarded (even for results like materials bay and goo, and presumably surface samples as well, though I haven't specifically tested those yet). Perhaps FS could be programmed to explicitly ignore the contents of the science storage containers? Better yet would be to test whether a certain result is already present in the pod it wants to move results into. It's obviously capable of doing something like that since it isn't constantly re-running experiments which have already been run. It just needs to perform those tests when moving results around as well, and not move them if they're the same.

This excellent mod comes with one particular minor nuisance that just keeps driving me nuts (and slowing down my craft-building). A little background: When using the translate tool (2), either with or without editor extensions, I pretty much always have to switch it out of snap mode. Snap mode frequently causes the part to shift position along axes other than the one I'm dragging, forcing me to re-place the part and start over, and the positions it snaps to are generally not very useful anyway. It's a lot better to have fine control anyway (even if it didn't ever cause parts to jump in unwanted directions). Toggling angle snap with the usual keyboard shortcut (C) is quick and easy without editor extensions installed -- one keypress toggles it off and back on -- but with it, you have to hold shift and tap it several times to get to no-snap mode, then tap it several more times to get back to your preferred snap setting after you're done moving the part(s). The only alternative seems to be clicking the icon with the mouse, which toggles it directly to no-snap and directly back to its former setting, but this requires moving your mouse a long ways away from the part you're trying to manipulate (and then moving it back). Either way (keyboard or mouse), getting it switched into no-snap mode just to slide one part around a little and then returning it to the usual setting requires a lot more time and attention to detail than it should. Could you add the ability for each of the translate, rotate, and place tools to independently remember whether angle snap mode was on or off when that tool was last used, and automatically toggle it appropriately when switching tools? (Maybe remember which angle it was set to as well, not just whether it was on or off. Whichever you think would be easier and/or more useful.)

I dunno, I kinda like the Nyan Cat, his/her/its smooth rainbowy progress across the screen lets me know the game hasn't frozen up while loading. XD But seriously, thanks for getting Trajectories updated! It's so incredibly useful (even if I am usually just trying to maximize recovery funds)!

Hi, I've narrowed down a strange UI glitch in the VAB to having version 2.2.6 of IFS installed (and nothing else except for Module Manager and the CRP it comes with). When displaying (by pointing at or clicking on) the Engineer's Report or Contracts options on the stock toolbar, they are frequently not drawn correctly, with the text either absent or covered up, although some icons are faintly visible. While moving the mouse around, this effect flickers, and it's possible (but very tricky) to stop the mouse pointer in positions which make them display normally, but as soon as you move it the problem reappears. The load craft menu, if a sufficiently long list of craft files is present, also exhibits display glitches, with part of the craft list appearing near the bottom edge of the screen as you scroll the list. This effect happens only when the contracts and report options look wrong, and also flickers as the mouse moves. KSP.log: http://pastebin.com/C56ZqQG7 Screenshots: http://i.imgur.com/1YcbgM6.jpg http://i.imgur.com/2jYbQ6D.jpg (Yes I know two of those show KER and Transfer Window Planner on the toolbar. Those pictures were taken while I was in the process of removing mods to find out which was the cause. The problem happens only if this mod is installed, regardless of what else is.)

Eh, I always just saw getting more science for running those experiments again as a minor challenge to be met, particularly when designing probes -- it's another advantage of manned missions (being able to get multiple results without needing redundant science parts). And it makes sense that you would want multiple samples to study, it's just a nuisance that the base game allows you to collect as many different experiments as you want in a single container *except* when they match, it won't just say "Hey, this contains TWO of this one and that one," even though you *can* bring two (or more) of them back by putting them in different parts... It's a silly restriction that makes no sense since it can be worked around so easily, just like it makes no sense to have to take the crew report out of your command pod in order to take another crew report, even though you're just putting it *right back in*... and how transmitted data is worth less than bringing the readings home, even for experiments where there's no physical test subject to perform a detailed lab study on (I'm looking at you, 2HOT & co.) Anyway, I could test FS's behavior myself under those circumstances, it would just take enough time to run a mission to somewhere I haven't already studied, which could have been wasted if it turned out to cause undesired behavior. And someone might already know the answer before I get to it.

How does this mod behave in regards to taking multiple copies of the same experiment for the additional science value? Surface samples, materials bay, and mystery goo can all be performed multiple times, whether you've transmitted the results, previously recovered them on Kerbin, or simply taken the data out of the experiment (or stored the sample in the ship and gone back for another). If you have multiple objects that can contain experiment results, like a command pod, hitchhiker container, or the new dedicated science container part, you can store one copy of each experiment in each different part, and when you recover the vessel, you receive the full amount for the first copy and the additional bonus science award for each extra copy, with each award being a certain fraction of the previous award). Because you cannot store multiple copies of such experiments in the same part, due to the duplicates simply getting discarded, the only way to do this on a single trip is normally to collect the first results, store them, re-run the experiment, collect those results, and store them in a different part (or for a probe, just bring along multiple experiment modules so that no collection and resetting is required). With this mod automatically running experiments and collecting results, how would it handle a situation where I manually run (for example) a materials bay a second time? Would it recognize that the duplicate results would be lost and store them in a different science results container, would it leave them in the experiment, or would it collect them and overwrite the existing copy in the part it wants to store all the results in? Also, if I load up a vessel which already contains more than one copy of an experiment in different parts, will FS try to consolidate those experiments into a single part (resulting in loss of the duplicates)? Similarly, if I take multiple surface samples and stash them in different parts before re-entering the vessel (or stash the first in a science box and then board the command pod with the second), the same question applies?

Is there a way to get the beta version from CKAN? (I'm not sure if there's some trick to it or if it just hasn't been made available there yet. I can always just install it manually, of course, it's just that CKAN makes mod management so much nicer.)

When updating from 1.4.5, AVC "changelog" button currently displays a big scrollable window full of raw HTML that doesn't seem to contain any actual changelog, but it's hard to tell (I think it expects plain text and is getting something else -- I've seen it do this for at least one other mod too).

When the update appeared in AVC, the change log button gave me a large window full of HTML, and the download button was still pointing to kerbalstuff. I assume that's just the fact that the currently installed version provides those links, and the new version will have at least the correct download link for future updates?

I've been wanting this back ever since I got back into KSP recently... and finally found it. And it has even more features... Strut Alignment?! So awesome. Thanks for keeping this wonderful tool alive.

I, uh... think that's a bug, although I have no idea if it's MRS's. This contract was created using the version of MRS prior to .12 if that's important, and I don't remember seeing anything about this in the change log... I was able to save Rathy by editing a quicksave file (after backing up persistent of course) and changing the part type to mk1pod, then loading that save. Stuff in gamedata, for other installed mods reference: http://imgur.com/rVywN6o

Selecting download from the KSP-AVC popup in-game still sends you to kerbalstuff.com which gives a 404 error (as with all kerbalstuff links). Can you update that, please? It's such a useful time-saver (when the links work).

This is really confusing. The Universal Storage versions of many parts seem to be strewn about the CTT tech tree almost at random. I was getting very frustrated because I couldn't even find several of them - until I started hunting in the config files, and even then I ended up having to look in the KSP log to locate the module manager patch that was actually responsible for placing the US parts where they are. What are science wedges for rockets doing in aircraft parts nodes like subsonic & high altitude flight, specialized flight systems, and heavy & experimental aerodynamics, when the parts they supposedly contain are in totally different (and far more sensible) science-related nodes? Why is the RPWS wedge in Actuators while the normal RPWS is in Space Exploration, along with the barometer? And why is the Accel/Grav wedge in Advanced Unmanned Tech, which you can also get without picking up either of the stock devices it combines? It's almost as if they were moved out of the sensible nodes listed in the default patches on each part purely for the sake of placing them in different nodes in the CTT version of the tree... Not that some of the normal tech tree locations for the US wedge versions make significantly more sense. Normal GORESat in Advanced Electrics, with the US version in Precision Engineering with the SALLI instead? Why not put the US version of each part in the same node as the normal version, in both versions of the tech tree? I can't see any benefit to splitting them up. It seems to me that it's just a recipe for unnecessary headaches. Don't get me wrong, I absolutely love this pack. This was one of the first mods I looked for when I got back into KSP shortly after hearing it had finally hit the "1.0" release and playing stock for a while to get used to the various career mode additions I'd missed in recent versions. You've done so much exceptional work on all of these great parts, and all the standard versions of the parts seem well placed in the tech tree. And I love the models and animations for extending the GORESat and telescope from the US wedges! It just seems like the tech nodes for US versions of the parts could be more sensibly chosen, for consistency's sake. If nothing else, it would've avoided the frustration and confusion I just went through trying to figure out "what was wrong with my install".