madlemur

Hmmm... I don't know of a mod like that off-hand, and I'm not nearly a good enough artist to whip one up. Using mods I do know about, you could probably build an armature in IR that would pick up or place the rover on the ground. If the rover doesn't need to go back inside, you could even do an RCS sky crane... I hope someone with the requisite talent is interested enough to build up this part for you. Seems like it would make an interesting complement to the standard cargo bay (shown).

So... You want this for your lander? I'm trying to imagine what you're thinking of, and if you couldn't do the same thing with IR and some creative girdering, or cargo-baying. BTW, I'm not trying to shut you down or devalue your request, just thinking if your design requirements can be met with existing technology. You want to be able to build your lander as a vertical stack, with engines, tanks and heatshields on the bottom, the rover bay/ramp, and then the control pod/science stuff/non-landing-specific parts on top? Hmmm...

Slacker... Although the real answer is in the next sentence: Just another shovel in the sandbox for modders to use!

.675m drive with a zippy little capsule bubble. Make setting up a comms network around Jool a lot swifter... Bonus points if you can do it without having to tack maneuvering thrusters on your probe...

I really hope that DDSLoader support will be added. I believe that all that needs to be done is to make .dds files valid in LOD. There may be other optimizations that would be handy, but I think that's be bare necessity. Now, I don't know if LOD loads the textures, then writes them back out as DDS files in its cache (in which case, there's a duplication of data that's unneeded), or if it is storing something else. Regardless, if LOD is loading textures on the fly, DDSLoader will help immensely, as those load times will shrink. The dangers of doing too much, too fast in the VAB or SPH are much reduced, since there will be a smaller window during the texture loads. Also, unless LOD implements its own TGA loader, it's still relying on the leaky bucket Squad gives us (that ATM overrides)...

NOOO!!!1!!1!!!!eleventy-one! Y U H8 STOKK TEK TRE33??? Seriously, I think TM and CTT are light enough to be a hard dependency if you feel strongly that your mod doesn't fit into the stock tree. But I do appreciate that it's possible for a mod to support CTT without having a hard dependency.

Massive modding required. Or, get Space Engineers...

Ow. Wholly run-on sentences, Batman! And a complete lack of capitalization or non-comma punctuation. I know it makes me sounds like a pedantic twit, but please, please structure your prose a little. I got through your parenthetical, but then had to stop; it had become just a soup of lower case letters... Whitespace, capitalization, and punctuation are very useful when communicating via the typed word. As are emoticons...

Only if you dip them in chocolate and roll them in chopped nuts...

How do I "force" the client to recognize that I have a pre-existing mod installed that it didn't install? And when it does recognize them, it usually lights up the upgrade checkbox, which is useless, since it "fails" the upgrade because it won't overwrite the files. I found the only way for CKAN to manage my mods was to uninstall them, and let CKAN install them from the cache. Which would imply that if an unmanaged mod I use becomes available via CKAN, I'd have to uninstall it and let CKAN re-install it. This same issue bleeds over to dependencies. If you see I have Firespitter already installed, don't try to install it again...

Common confusion. That's indicating that Tech Manager is disabled. Uncheck the box, and you'll be able to select the tech trees you want to use. Yes, you can select multiple trees, and switch between them in R&D. Blame Unity's crappy UI widgets.

I just tried the RC, and I keep getting errors about files already being owned by ''. In order to get around the error, I had to go in and delete the mod, then I could update/add the mod. This is trying to get CKAN working with a fully modded install. It auto-detected about 2/3 of my mods (seems to miss parts only mods). And most of the mods it auto-detected offered updates (despite being the latest version). Overall, great idea, but I don't have the time to fight with it.

This was taken from a career mode save, but it was the same error that was seen in sandbox as well. I've seen the same thing since I started using Snacks early on, but I've always had bigger issues (and much smaller framerates) to deal with... I've seen in it in career and sandbox games. I also see that it's a log message, and not a warning or error... But still, that's an ominous message if it's not indicative of something wrong. Ah! I see the problem (I think)... In SnackController.cs line 185 (FixedUpdate), currentTime is initialized at declaration, and I'm guessing that there is no Planetarium (or at least, no way to get the universal time) if you're in the VAB/SPC or during loading. I'd suggest initializing it to 0.0 and then testing to see if Planetarium.GetUniversalTime is available before calling it. void FixedUpdate() { try { double currentTime = 0.0; // If Planetarium.GetUniversalTime() is available, set currentTime if (currentTime > snackTime) {

Two things: I love the rounded, almost chubby husky look to the parts. And I immediately had flashbacks to Martin Landau, Barbara Bain, Barry Morse and bell bottoms, and I really, really want a Space: 1999 parts pack...

OK... Tell me more about Function 2, Step 3... How are you crossing and mutating the rockets? What variables (chromosomes) are you using?

Heh... In Computer Science, genetic algorithms are self-rewriting algorithms, or more generally, the algorithms mutate, not the input/output (well, not directly). What you're doing is applying genetic theory in an iterative optimization algorithm. Interesting idea, though. Are you determining some ideal "child" engine specs, then finding the closest match in the set of available engines?

I tried to pull the source and recompile with what I thought would allow DDS textures, but I don't have the DirectX9 SDK, or the db SDK that's being used, so I abandoned my attempts at a proof of concept... I hope that DDS support does get baked into LOD. I can't go back to 5-10 minutes loads, and I'd like to use LOD.

What about thrust plates and using multiple small engines with larger tanks? That really opens up some new permutations...

Ummm... The .version file you packaged with 0.13 still has the version at 0.12, which agitates KSP-AVC...

Let me put it this way: Back in the day, I cancelled my WoW subscription when I realized I was only logging in to the game to test whatever add-on I was futzing with, and I was no longer playing the content. With KSP, I've started quite a few careers, but then I start getting all OCD ADHD with the add-ons, and I break my current save and have to start over...

Yeah, an installation manager would be great, but I see your point. Can they have different nodes? If you maintain the node id across trees, will it remember what's been unlocked? Oh, my... The mind boggles... Ow! Owow! edit: I would have realized that if the damned Unity checkboxes didn't look like radio buttons...

Oh, hell no. When I say "co-bundling", I mean the archive has a GameData directory, and under that is TreeManager and CTT in separate directories. There is no reason to put someone else's plugin inside your mod. Just put it in its correct location. I can see that, but if you use AVC or something similar, even if it's bundled with another mod, the user will be immediately notified if they have an out of date version. Hrmmm... Forgotten that tidbit. TM can switch between trees in-game? That could be... useful.

@PringleMan, Also, look at Real Chutes. You can set your predeployment and full deployment altitude. Then, you just arm your parachutes and wait... For your drogues, is the 30km default based on stock or FAR aerodynamics, and with/without DRE? It seems pretty high to me. I'd suggest letting your heatshield do the brunt of the aero-braking, then pop your drogues at the appropriate velocity, and finally your main chutes at the right velocity (I usually deploy my Mk16's at right around 300m/s, which I try to aim for 5km altitude, with a full deploy at 700m).

You could do like MM does, and incorporate the TM version into the filename of the DLL. If you could also borrow the logic to only use the most recent version, the problem kind of goes away. Even if someone distributes an older version of TM, it won't overwrite a newer version, and the version checking would cause only the newest version to actually run. I'd like to take a minute to review the use cases I've gleaned from the thread... 1) A mod wants to be "CTT-Compliant" The mod builds everything out with parts in the stock tree, but provides a CTT cfg file to place them in the expanded nodes as needed, if CTT is being used. 2) A mod wants a hard dependency on CTT, forcing the user to use the expanded nodes The mod builds everything out with the parts in the correct nodes from the expanded CTT set The mod either leads the user to install CTT as a prerequisite, or co-bundles CTT with their mod 3) A mod wants to rearrange the CTT nodes to better fit their preference The mod builds out everything per #2, but also includes their own tree.cfg that includes all the CTT nodes 4) A mod wants to rearrange and expand the CTT to better fit their vision Per #3, but we're starting to drift away from the CTT at this point, since they are adding new nodes, and likely won't be able to reassign any mod parts other than their own Note that this is probably the use case for complete re-theming mods (like BTSM) that are meant to be comprehensive and self-contained, but it's also comparable to just having a flat-out custom tech tree Caveats: In cases #1 & #2, the mod builder should not base any part-node assignment based on node dependencies (except perhaps "XX", "Advanced XX", "Mo' Bettah XX", "Trancendental XX" style progressions) In case #3, the tree modder should not take into account what parts are in what node for determining dependencies (except as noted above) In case #4, the modder is on their own, and it's assumed they know what the heck they are doing. Now, how does one "install" the CTT? My suggestion is that even if the "mod" is just one tree.cfg file, it should be in its own directory, and either be co-bundled with TM, or have big ole' warning text that TM is a prerequisite. Personally, I'd go with co-bundling it (if the license allows, I haven't read the license). This would be akin to the co-bundling of MM and Firespitter that so many mods do. TM and CTT are relatively small mods, so byte-bloat isn't really an issue. Version checking in TM would solve overwrite issues with that. That leaves two issues: CTT overwriting & CTT usage checking. CTT Overwriting: I'm not sure we can prevent overwrites, unless the file is also named with the version number, in which case the user has to be sure to choose the correct version. Or if TM incorporates a way to do versioning. CTT Usage Checking: This is the tough part. How do we check that the user is actually using the CTT? How can we communicate that back to MM? Assuming use case #1, the additional MM patches should only be applied if CTT is the active tree, not just if it's installed. I don't know what could be done with a simple plugin that checked which tech tree is being used, and unloaded itself if it's not being used (allowing :needs[CTT]), or some other method for toggling MM processing. Will there still be problems? Sure. Every time you foolproof something, the universe comes up with a better fool.

The WHEN clauses are events, not tests. Move them out (and before) the UNTIL loop.