AccidentalDisassembly

FYI - In the Parts/FuelTank/RadialAdaptLG directory, it looks like you intended there to be three separate/different parts, but they're all identical in the VAB.

Think I found a repeatable bug with the prerelease, possibly applies to earlier versions but not sure. Steps: - Put homstead module in the VAB, change it to whatever type. I tried the Machinery Plant. - Duplicate it by alt-clicking, then place it. It will now have lots and lots of different resources in it - more than intended for that module, I think. May be all of the possible resources...

Gotcha, thanks.

Had a question - when I build something via the orbital dock, I have the option of transferring in resources and whatnot. When I build via survey stake location, is that not possible? I can't seem to find a way, except to run some ground pylons w/ tubes and stuff out to the survey stake so I can go fuel up whatever I build...

So... dunno what's going on here, but I think maybe there's some sort of bug with moving survey stakes. Here's what happened: 1. Switch to outpost on the Mun. 2. Build something on top of a survey stake - no problem. 3. Survey stake was called Cleared Area: felt it was too far away from base, move closer. 4. When I move it, "Cleared Area" remains in the list of build sites but another one is added with the name of the Kerbal who moved the stake (not shown, sorry). 5. Try to build something: now EPL thinks there are zero rocketparts in my base. Screenshot demonstrates this isn't the case. Screenshot: Output log: https://dl.dropboxusercontent.com/u/59567837/output_log_EPLnoRP.txt Is it because I moved the stake? Or is some other trickery going on here? UPDATE: Returning to the space center, then returning to the base seems to reset whatever happened. UPDATE ON UPDATE: Actually, sorry, what I actually did was rename the moved stake to something new ("New Site"), then return to space center, then return to base. That seemed to clear things up.

Once you've finished that, is there any chance you could provide a list of the part configs, models, and textures in the USI folder that aren't needed anymore with your mod installed? That'd be handy... stupid RAM. =(

Not being functional in any way (for me) is probably its principal downside. It doesn't detect versions of installed mods and therefore can't tell me if there are updates.

Found a bug that can be reproduced: placing the multipurpose storage module in symmetry and changing storage type, then attempting to right click on it after changing breaks right clicking in general in the editor - loading/making a new craft seems to reset it. To duplicate it, just place the MSM in symmetry, right click it, change storage type, then you can't right click on anything. Symmetry is key.

One issue is that it is much, much easier to tweak values, update things if something like MFT needs changes in its syntax, whatever - both for the modder or for the end-user, since lots of us end-users like to fiddle with things too - if modules like Modular Fuel Tanks / TweakScale / whatever are loaded via MM config. MUCH easier. One file to edit in order to change an entire dependency's interaction. It may be a tiny bit less efficient, but it's so much easier to manage I think it's worth it. Likewise, an end-user can then also decide "I don't like MFT!" (or whatever) and simply delete that ONE config file rather than editing every single part's config.

CollisionFX is working on different dust for different landscapes, methinks..

OK, found the source of at least SOME of the errors in that MM config - one bit needs an @:

Sorry if this is a dumb question, but just to make sure I understand: let's say I apply the "Default" TANK_DEFINITION to a part. It has within it "basemass = 0.000625 * volume", so that means that anything with that MFT definition applied to it will have this new base mass, right? Not that this basemass = X will be added to the part, but instead it will be recalculated? And then specific TANK definitions could also add mass, like: TANK { blah blah blah mass = 0.000625 // adds 0.000625 tons per unit of volume, so every 1,000 liquid fuel capacity (for ex.) would add an ADDITIONAL 0.625 tons to the basemass = 0.000625*volume thing } Is all of that correct?

Not sure what the difference between a cryogenic tank and other tank is (in real life I understand, but not in KSP), but here's what I've come up with. The reasoning behind the numbers is to approximate the amount of Xenon, Argon, or Liquid Hydrogen you get in a Near Future tank when compared to a stock tank of the same volume. This necessitates changing MFT's Xenon utilization to 14.5 rather than 56 (!). The 56 number is based exclusively (I think) on the small stock stackable Xenon tank, and is wildly more than you get in the same volume from a NFT tank. Opinions may vary on the right numbers. I use the Default tank type because I have patched it using an MM config to include NearFuture, EPL, and maybe some more resources - slight mass penalty for stuff like LiquidHydrogen or ArgonGas that probably need a bit more robust tanks (or cryogenic or whatever) to store. I added :Final to all of this because I figure that way, if I forget to delete any configs, these will run last and the check for !MODULE[ModuleFuelTanks] will avoid accidental duplication. Some mods have their own MFT definitions in their own directories, so I thought the MFT directory and its patches might get applied first, etc. etc.

So would this do what I'm looking for? Which is: 1. Find a part with LiquidHydrogen in it 2. Apply MFT to that part, but 3. Set the "volume" of the MFT tank to be the amount of LiquidHydrogen divided by 2.5: Reasoning being that LiquidHydrogen, for better or worse, seems to have about 2.5 times the units in the same volume as something with liquid fuel (so that it will balance about right with NFT tanks)

Maybe something with "grip"? The Grip-o-tron 9000? Etc.

That sounds like a good idea! I am not familiar enough with regex (?) to interpret some of what's in there, but I assume there would also be a way to replace a xenon tank with the "Default" tank type by dividing the amount of XenonGas present in a part by 56 (I think) to get the right volume for liquid fuel / oxidizer...? And to do the same for things like NearFuture resources (divide LiquidHydrogen by 2.5, I think, ArgonGas by something crazy), and really anything else? Reason I ask is because I've patched the Default tank type to be pretty much universal - can have ElectricCharge, Xenon, ArgonGas, Karbonite, Metal, RocketParts, etc. etc. It would be really cool to have just one config like that, matched to volumes/densities/whatever as laid out in CRP or some such.

Don't think the link works... EDIT: Derp derp derp. The one in your post doesn't, but the one on the first page does... ugh, need to think before posting.

Here is a link to an updated Squad_modularFuelTanks.cfg that I made. It removes duplicate entries with former SPP parts and merges everything from SPP into it. Can remove SPP.cfg entirely with this version. Link: https://dl.dropboxusercontent.com/u/59567837/Squad_modularFuelTanks.cfg

If you're also adding the MODULE{} named TweakScale to your parts, and then using that SCALETYPE within the module, you may not have to do anything extra. If I remember correctly, TweakScale already handles various aerodynamic values (you can check for their variable names in ScaleExponents.cfg), but I'm not positive. That SCALETYPE as it stands however won't do anything that tweakscale doesn't already to to the aerodynamics of the part, just FYI.

Looks like a .png file is missing from your download. Haystack is telling me this in the log: AddonLoader: Instantiating addon 'HaystackResourceLoader' from assembly 'HaystackContinued' (Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49) IsolatedStorageException: Could not find file "C:\Games\KSP_win\GameData\HaystackContinued\icons\button_vessel_spaceobject.png". at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0 at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0 at System.IO.File.OpenRead (System.String path) [0x00000] in <filename unknown>:0 at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <filename unknown>:0 at HaystackContinued.Resources.LoadImage (UnityEngine.Texture2D& targ, System.String filename) [0x00000] in <filename unknown>:0 at HaystackContinued.Resources.PopulateVesselTypes (System.Collections.Generic.List`1& list) [0x00000] in <filename unknown>:0 UnityEngine.Debug:Internal_LogException(Exception, Object) UnityEngine.Debug:LogException(Exception) HaystackContinued.Resources:PopulateVesselTypes(List`1&) HaystackContinued.HaystackResourceLoader:Awake() UnityEngine.GameObject:Internal_AddComponentWithType(Type) UnityEngine.GameObject:AddComponent(Type) AddonLoader:StartAddon(LoadedAssembly, Type, KSPAddon, Startup) AddonLoader:StartAddons(Startup) AddonLoader:OnLevelWasLoaded(Int32)

What makes you say that? Have they said something? And I can only wonder what "soon" means...

Huh, I used to have a similar problem with hangar (at least I think it's similar based on your description) - I could sort of drive partway into one at low speeds, but wheels wouldn't grip the floor. Had to go full throttle and hurl my vehicles inside. Haven't had a chance to use hangar in my career recently, I wonder if that issue is still around...

Huh, so what I gather from that is that, for example, it might be vaguely possible to somehow make it so that you can place static, non-spawn/non-launch-point objects off of Kerbin using EPL resources (integrating the two just a little bit for certain cases, like: find a container with RocketParts within X kilometers and deduct some), but using an EPL part as an actual launch point near those static objects might be less bounce-y or less problematic than spawning directly from the VAB at a KK site and somehow magically requiring nearby RocketParts to do that, assuming that could be done as well...

With regard to the funky mashing of model shapes, which does indeed look very weird, would it be possible to create a model in two sections, where the door section doesn't resize and is simply repositioned while the "box" section behind it DOES resize? To avoid squashing/stretching the door and whatnot?

I thought I read somewhere else in the thread that implementing bases on bodies other than Kerbin might be very difficult - sorry if this has been asked 1,000 times, but is it simply difficult, or is there something in the game that absolutely prevents you from, say, establishing a launchpad on the Mun (and maybe somehow using RocketParts from a nearby somethingorother to create stuff, or whatever kind of construction process)?