Crater

Told you it was untested! Thanks - I've corrected it (renamed the part) - it should (now) add a separate part that has science storage, but no Modular Tank.

True, but you could always add MODULE { name = FNResourceScanner resourceName = Water mapViewAvailable = true } to a scanner part to make a detector.

You mean something like the following (untested) config? PART { // --- general parameters --- name = ScienceTransferBag module = Part author = Albert VDS // --- asset parameters --- model = CargoTransferBag.mu scale = 1 rescaleFactor = 1 specPower = 0.3 rimFalloff = 3 alphaCutoff = 0 // --- general parameters --- node_attach = 0.0, 0.0, 0.0, 0.0, 0.0, -1.0 attachRules = 0,1,0,1,0 // --- editor parameters --- TechRequired = survivability entryCost = 2800 cost = 340 category = Utility subcategory = 0 title = Cargo Transfer Bag manufacturer = VDS description = Test // --- general parameters --- mass = 0.07 dragModelType = default maximum_drag = 0.2 minimum_drag = 0.3 angularDrag = 2 crashTolerance = 12 breakingForce = 400 breakingTorque = 400 maxTemp = 2900 MODULE { name = ModuleScienceContainer reviewActionName = Review Stored Data storeActionName = Store Experiments evaOnlyStorage = True storageRange = 1.5 } MODULE { name = KASModuleGrab evaPartPos = (0.0, 0.2, -0.22) evaPartDir = (0,0,-1) storable = False //storedSize = 16 attachOnPart = True attachOnEva = False attachOnStatic = True attachPartSndPath = KAS/Sounds/attachTape grabSndPath = KAS/Sounds/detachTape } MODULE { name = FStextureSwitch displayName = Cargo Tranfer Bag Label moduleID = 0 switchableInFlight = True textures { name = CargoTransferBags/Parts/CargoTransferBags } objects { name = CargoTransferBags } } } Stick it in a .cfg file in the same folder as the rest of the bags, add any textures you want to switch between down at the bottom, and presto.

You made one slightly flawed assumption - that water was present everywhere on Minmus. It isn't. If you want the cheat sheet, you can take a look at GameData\WarpPlugin\PlanetResourceData\minmus_water.png and the other pngs in that folder - they're the distribution maps for where you can find given resources, and their relative densities. I currently have an ISRU on minmus and it is happily extracting water, and turning it into fuel for me, so the mechanics do work, it's just a matter of placement

Ahhhh, I thought of that as diagnostic testing. Removing the decoupler or the solar panels module allows you to build and launch a ship, but for me the unit isn't really usable without either of those (though I guess I could stick an extra decoupler in between them, but UGLY)

What's his fix? All I saw was some problem isolating steps, no sign that Fractal_UK has any idea what / why it might be happening, or that he's got a fix in mind for it?

I think it was passed over because it isn't clear what you are asking. If you are creating a new part with a custom mesh, you don't need to use MM to set it up, you just need to add the appropriate MODULE into the part.cfg file. I believe the module in question is MODULE { name = DTMagnetometer animName = deploy } On the other hand, if you're trying to add the function onto some other existing part, the MM config for it would be something like @PART[insertPartNameHere] { MODULE { name = DTMagnetometer animName = useCorrectAnimationNameFromYourPartHere } } You'd need to insert the part name and the animation name, or if the new part isn't animated, just delete that line from the config, though I have no idea if the MODULE will still work without an animation.

Sorry for the slow reply, but I wasn't in a position to test, either - the place I work frowns on me playing video games in the office 1 and 3 completely fix the errant behaviour. the stages all appear, the panels extend, etc.etc.etc. 2 does nothing, apart from removing that (purely visual) animation from the part. As one final test, i removed just the ModuleDeployableSolarPanel, and sure enough, everything worked fine. So it seems that it is a combination of a solar panel and a decoupler on a single part that is making it go sideways.

That would only be true if you were staging away engines. If you're only dropping tanks then fuel use won't vary when a set go dry.

They're simply gorgeous! Of course, it does mean that I'll have to re-design my resupply ship now, to build around them!

Picking up from where Wasmic left off, here is a brief description of the problem and repro method 1) take a stock KSP install 2) install CardboardBoxProcessor's Dragon Capsule addin from http://forum.kerbalspaceprogram.com/threads/26243-Dragon-Rider-Capsule-0-23-%282-14-14%29 3) try it out by loading the prebuilt craft supplied in the mod, it has a pod with a "trunk" below it, which has solar panels as a part of it. Everything works as expected 4) install KSPI 5) load up the sample craft again. This time, although it looks fine in the VAB, once you get it onto the launch pad, the connection is broken below the pod - half the staging is missing and the trunk and below is simply not part of the craft - you can even switch vessel to it as a separate entity. ALso, the parts that were previously attaced to the trunk are now floating magically suspended where they were, with no sign of them believing in gravity. Sadly, there are no errors at all in the log, not even related to the disconnection. The only sign that anything at all has happened is that there is a warning that the game cannot save while there is a vessel flying [LOG 20:42:31.367] cBBp.Dragon.Wings is in atmosphere. Cannot save. [WRN 20:42:31.368] [FlightPersistence]: Vessel Dragon_Assembled Ship not saved because it wasn't clear to save: NOT_IN_ATMOSPHERE I grabbed a video of it misbehaving. Hope it helps. I normally run with over 70 other mods, and none of them cause any trouble with the Dragon, nor with KSPI. Personally, I wouldn't call it a bug report against KSPI, just a really weird interaction between the two mods. cBBp also has a dll that is used for some animations on the parts, but that works just fine with KSPI installed, at least, it does on the pod part, the trunk is a different matter. Any thoughts on what might be causing it? We are guessing it might be related to the solar panels in some way since that's about all KSPI would touch in it. KSP.log : https://dl.dropboxusercontent.com/u/2652591/Dragon/KSP.log output_log.txt : https://dl.dropboxusercontent.com/u/2652591/Dragon/output_log.txt Edit: That error is most likely a red herring - it is simply a result of trying to predict the orbital position of a landed craft, which could be targetting, maneuver nodes, or some other mod. I didn't see anything like it when I did the testing above.

You know that there already is a lowres texture pack on the front page?

Uhhh, it is already there. Though the release notes (also in the first post) do say that in 1.06 an initial framework was added for support for both FAR and DRE, and in 1.09 a little more work was done on DRE. The actual current state is that there is a FAR compatibility config posted somewhere in the thread, and a mod for the DRE config was posted a couple of pages back.

Use a download manager, something like Free Download Manager - the Spaceport has a nasty habit of truncating large downloads, a download manager will restart them and get them to complete for you.

I'm not disagreeing with what you're trying to achieve, I was just trying to point out that there is no craft file to read for a loaded vessel. While you are in the game, the only possible source for information about a craft is the in-memory game object. This is periodcally flushed to the persistence file (which is similar in layout to a .craft, but not quite the same), but your information source, which you will have to work from for any in-game operations will have to be walking the current tree and building your optimized data structures, not parsing .craft files.

Are you thinking about this as an in-game tool, or separate app? I ask because, if you're planning for something in-game, then you most likely don't want to work with craft files, but with the in-memory vessel objects that KSP is using to represent the already loaded and parsed vessel, which would mean that you'd need more of a tree walker than a parser, and I think from what you're saying, layer one is already implemented within the game, and you could get straight on to layer two?

0.10.3 - the lastest release I'll take a look through what changes KSPI makes to panels and see if I can work out what the heck is going on Agreed, it totally slipped by me that the trunk was also a solar panel, and yeah, everything on the pod works - all the lights, the ladder, the engine, the RCS. No probs at all, so it isn't anything fundamental to your plugin dll. Categorically no. Most plugins work fine. Here is a list of what I have in my normal game, and it works perfectly if I remove KSPI (WarpPlugin) 000_Toolbar AmericanPack ASET - Stack lights and ALCOR Pod B9_Aerospace B9_Fixes_By_ModZero BahaEPL BobCatind BOSS BoulderCo - Visual Enhancements and Texture Management CactEye cBBp cBBp_Dragon ConnectedLivingSpace CraterMODS - loads of MM tweaks and a few cloned parts DeadlyReentry DistantObject EditorExtensions EnhancedNavBall ExsurgentEngineering ExtraplanetaryLaunchpads FerramAerospaceResearch Firespitter FusTek - Sumghai's current experimental build Goodspeed HexCans HullCameraVDS Hyomoto JSI KAS Keramzit KerbalHotSeat KerbalJointReinforcement KESA Kethane KineTechAnimation Klockheed_Martian KSO KSPX MagicSmokeIndustries MechJeb2 MechJeb2RPM ModsByTal ModularFuelTanks ModuleManager_1_5_6.dll NavBallDockingAlignmentIndicator NavyFish Nereid NMB NothkeSerCom nothke_DROMOMAN OpenResourceSystem PartCatalog PorkWorks PreciseNode ProceduralDynamics RCSBuildAid RealChute ResGen SCANsat SCANsatRPM SDHI SelectRoot ShipManifest SH_mods SomnambulicAerospace SpaceplanePlus Squad SurfaceLights Targetron ThunderAerospace - TAC Fuel Balancer and TAC Life Support TreeLoader TriggerTech - Alarm Clock and Alternative Resource Panel VesselView VNG WarpPlugin - this is the only one that causes me any issues with the Dragon capsule So yeah, that's why it took me almost 2 hours to isolate which one was causing the error, and yeah, I have too many mods

Well, no wonder I didn't find the offending addon last night - I started at 'A'... It was WarpPlugin - Kerbal Interstaller. I have no idea why, but with just interstellar and the Dragon, I get the broken behaviour every time. I have grabbed a video of it for your viewing pleasure. Hope it helps.

Ditched that long ago - it seems to break far too many things for my taste.

It's.... strange. I spent a full hour trying to work out what the conflict is here, but ran out of time before I had anything definitive to report, but here's some info for you. I get the same results whether I use the supplied pre-assembled .craft file, or try to assemble my own, so it isn't anything there. The test craft I use is basically the prebuilt .craft with a stock launch clamp attached to the pod itself. I cleaned down my install (cleaned down to no mods, no stock parts apart from the LSE, and the dragon capsule addon folders - boy, does it load fast!) - this configuration works perfectly! The craft appears on the launchpad with all stages present and correct - first spacebar drops the adapter, next one drops the solar panel covers and kicks off the nosecone, last one cleanly drops the trunk, all just as you'd expect. I then went through my mods, adding back a few at a time, starting with the obvious suspects. I can confirm that it continued to work fine with : Kerbal Joint Reinforcement (which was my primary suspect) FAR Deadly Reentry MechJeb Texture Compressor EditorExtensions Enhanced Navball Goodspeed Fuel Pump RPM Infernal Robotics RCS Build Aid Select Root Kerbal Alarm Clock but I ran out of time to keep adding more I finally tested with all my mods on a brand new save, but it still freaks out. Specifically, the fault condition (that I am seeing), is that before you get control of the craft, it has broken in some way. Staging only shows the command module and nosecone, but the trunk does not fall away. It still looks like it is in place, you just have no control over it. If nobody else comes up with anything, I'll try and install some video capture software and see what I can get for you.

I absolutely love this concept, though I'm not sure that you could ensure that such a module fired and moved the kerbals before the decouplers fired and split your living space into multiple sections. Definitely a great idea for a mod that utilized the CLS API (I just wish I had enough spare time to code it). ------------------------------- I have a minor bug to report.... or maybe an incompatibility.... or.... well anyway, if you use this with the PorkWorks inflatable habitats, CLS doesn't initially recognize them as living spaces, since they start off with a crew capacity of zero. This is an easy fix (see below for contributed config file), but even then, once they are passable they show as a single space, but when you inflate them the part (correctly) goes from yellow to green in the highlight as the gain crew capacity, but the numeric reported crew capacity in the CLS window does not update unless you switch away and back. Is there any way to get that display to change as well? -------------------------------- Finally, here are three more contributed configurations for you PorkWorks inflatable habs @PART[inflato1]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[inflato2]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[inflatoFlat]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } SumDum Heavy Industries service module pack @PART[SDHI_ParaDock_1_ClampOTron]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SDHI_ParaDock_2_IACBM]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } ASET stackable inline lights (very thin, completely hollow, kinda cool) @PART[SIL02125mRGB]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SIL0225mRGB*]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } } @PART[SIL02375mRGB]:HAS[!MODULE[ModuleConnectedLivingSpace]] { MODULE { name = ModuleConnectedLivingSpace passable = true } }

Basically, the part most people start with is a docking port, which is capable of being surface-attached, which means that when you drag the part over from the menu to the ship, it will try to stick it to whatever is underneath the mouse, and only snap it onto a stack node in the case that your mouse cursor is hovering close to an available node, and not over a part to which it is possible to surface-attach something. I.E. if your mouse is pointing at the back of the cargo bay, or at the end-cap of the cargo bay, it will try to mount it there instead of on the stack node. Editor Extensions allows you to turn off this behaviour, and only use stack nodes. Burying your camera view in weird places allows you to effectively look out of the bay, so your mouse isn't over any part of the cargo bay part, so it jumps to a stack node instead. I hope that's clear?

Are you using any kind of download manager? A few days ago DropBox seemed to change their server-end stuff and it now fails on multi-streamed downloads.

Papa_Joe is already looking at incorporating it into his Ship Manifest mod, which does crew transfer and more..... can't wait!

Currently it is an all or nothing effect. However, it won't swap people around during (or for a little while after) manoeuvres, and only within a Connected Living Space, so it isn't that disruptive to the job at hand of actually flying your ship.