sumghai

tek, my understanding from last time is that you were attempting to decipher my ramblings on sample collection / planetary compositions / rare sample returns / resource integration. I'm pleased to hear that you're considering Kethane integration, although I'm mainly curious as to how you found my tome. Indeed - my measurements were only for standing Kerbals. Next time, I'll grab Jeb's Big Stick and an external command seat to get info on seating postures.

Snjo, I found out about your excellent parts animation module through my use of the B9 Aerospace parts - it's definitely nice to see multiple persistent animations per component I've been studying the documentation you've written for FSanimateGeneric, and while for the most part it seems straightforward, I was wondering if you or anyone have used this module with deployable solar panels? I'm asking because I'm trying to retrofit another modder's solar panels, which have problems with multiple animations per part. Said part is the Balka Solar Wings Block from CardboardBoxProcessor's Kosmos pack - it consists of two extendable/retractable solar "wings" mounted on opposing sides of a rotating hub. The combined rotation of both the solar wings and the hub usually allows the Balka to track the sun effectively, but when switching between flights, the panels would revert to their default retracted state due to stock KSP being unable to handle multiple animations per part. The panels are *enormous* such that it takes literally minutes to fully re-extend each wing. Below is a snippet from CBBP's original CFG file. // Right solar wing MODULE { name = ModuleDeployableSolarPanel animationName = open_right raycastTransformName = sunCatcherRight pivotName = ArmLeft01_main resourceName = ElectricCharge chargeRate = 200 trackingSpeed = 0.1 powerCurve { key = 206000000000 0 0 0 key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = 0 10 0 0 } } // Left solar wing MODULE { name = ModuleDeployableSolarPanel animationName = open_left raycastTransformName = sunCatcherLeft pivotName = ArmLeft01_main resourceName = ElectricCharge chargeRate = 200 trackingSpeed = 0.1 powerCurve { key = 206000000000 0 0 0 key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = 0 10 0 0 } } // Central rotating hub MODULE { name = ModuleDeployableSolarPanel animationName = rotary raycastTransformName = sunCatcherRight pivotName = Main_Rotary_Pivot resourceName = ElectricCharge chargeRate = 0 trackingSpeed = 0.1 powerCurve { key = 206000000000 0 0 0 key = 13599840256 1 0 0 key = 68773560320 0.5 0 0 key = 0 10 0 0 } }

I'd rather he didn't simply leave them be - it's very annoying to have to wait several minutes to fold and unfold the panels each time one switches craft. The latter option might be a reasonable compromise, assuming folks don't mind having to rebuild their existing stations. Yeah, I incorrectly assumed CBBP would've known about Snjo and his Firespitter mod, since quite a few other prolific mod makers like B9 already use it. Anyway, Snjo has also written a specific document on the FSanimateGeneric part module, which supports multiple animations per part. You'll need to contact Snjo to if id they work with the Solar panel's suncatcher system: CBBP, if I have some time off working on my FusTek Station Parts Expansion this weekend, I might experiment with the Firespitter DLL myself to see if I could retrofit the multiple persistent animation feature into the existing Balka(s). I'll pass on anything usable back to you.

You want proof? Sure thing.

CBBP, any word on the fix for the solar panels that retract when switching between flights?

First thing I'll do is to crash-test all the custom mod parts I've made for compatibility and performance. Then, if time permits, I'll recreate all my missions from scratch (I'm looking forward to starting afresh with a more sensible rocket family progression this time).

Full mission report is here, but essentially, other than some hairy moments involving fuel shortages and borked trajectories, I managed to get the crew back safely.

I LOLed so hard. Somebody make this the official lore of the species like, now!

I suspect it's mostly part count, and a bit to do with the FusTek parts. My own KSS consists of over 19 Karmony-sized modules, each with between two and six docking ports. Add to that a large number of B9 lights, docking struts, a large fuel depot and an extensive truss backbone, and my parts count is around 200~300+. And that's not counting the KES spacecraft(s) I use to ferry Kerbonauts to and from the station - it results in a rather agonizing slide show even on a PC powerful enough to do complex COMSOL simulations. The parts themselves aren't officially made by fusty, but by myself (he gave me his blessing to expand upon his work). I did my best to reverse-engineer fusty's original Karmony modules and optimize model meshes, and while most people don't have complaints, I do get the occasional report from users experiencing lag. Of course, you could always try the FusTek Station Parts Expansion 0.02.2a DEV BUILD, which has some minor performance fixes.

Having spent the majority of my time in KSP either A) Goofing around or Developing space station modules, I figured it was time I attempted one of the most basic milestones of playing KSP - landing a manned spacecraft on the Mun and returning its crew safely to Kerbin. Although this will be the first mission report I'll file on these forums, I haven't documented my earlier orbital manned flights / probe launches / space station construction simply because I didn't feel they were noteworthy at the time - I'll probably start from scratch once 0.21 comes out, though. But anyways... KES Munar 01 Mission Outline & Objectives - Manned landing on Munar surface - Acquisition of geological samples - Reestablish contact with unmanned Kerbal Munar Rover launched weeks prior and effect repairs Background By Joon1KY507, the Kerbal Space Administration (KSA) had successfully achieved the following milestones in their space program, since its establishment in KY500: - First Kerbal-made object launched into stable orbit around Kerbin (Kerbstar 1 satellite, 700 km circular equatorial orbit) - First manned orbital spaceflight (Maj. Jebediah Kerman, Kerbal 1 one-man crew capsule, 120 km circular equatorial orbit) - First polar spaceflight (Kerbstar 3 satellite, 650 circular polar orbit) - First extended duration orbital spaceflight (Maj. Jebediah Kerman, Capt. Bob Kerman and Lt. Bill Kerman, KES X-01 three-man Command and Service Module, 300 km circular equatorial orbit, 3 days 11 hours and fourty-five minutes) - First science mission (Kerbstar MapSat 1 satellite, 300 km circular polar orbit, 100% mapping coverage, planetary composition studies in progress) - First spacecraft to orbit a celestial body other than Kerbin (Kerbal Munstar 1, 200 km circular polar orbit around the Mun) - First unmanned spacecraft to land on a celestial body other than Kerbin (Kerbal Munar Rover, 12°29'44"N 39°12'33" on the Mun) - First rendevous, docking and crew transfer between two spacecraft (Capt. Seangard Kerman, Lt. Jerski Kerman and Lt. Genefred Kerman, KES-02 / Maj. Jebediah Kerman, Capt. Bob Kerman and Lt. Bill Kerman, KES-03, 250 km circular equatorial orbit) - First Kerbal Space Station component successfully launched (KSS Core, FusTek Karmony Utilities Module, 300 km circular equatorial orbit) - KSS "Core Complete" (16 crew capacity with two science labs and refueling depot by KY506) - Longest duration stay in space (Lt. Jerski Kerman and Lt. Kellas Kerman, KSS, 8 days, ongoing) Key to the program's ongoing success was the development, testing and commissioning of the Kerbal Exploration System (KES) series of three-man crewed orbital spacecraft, a versatile vessel with a maximum rated launch-and-return orbit altitude of 350 km primarily designed to ferry Kerbonauts to and from the Kerbal Space Station. Additionally, ongoing observations of Lt.s Jerski Kerman and Kellas Kerman aboard the KSS confirmed no significant or pernament negative effects on the physical and psychological health of Kerbonauts on long-duration space missions, especially in a low or microgravity environment. As such, KSA was confident that the KES series would serve as the backbone of long-term Kerbal manned spaceflight in years to come. Meanwhile, in late Joon KY507, KSA Ground Control attempted to remotely update the Kerbal Munar Rover's firmware - specifically, new software to manage the recharge cycles of its deteorating batteries. However, an incorrect function reference instead caused the remote command to accidentally erase the rover's antenna beam pointing code, resulting in a loss of contact by the next rotation of the Mun. This, coupled with scientific and political pressures to top prior achievements was the driving force behind the first KES Munar mission. Mission Profile Various mission architectures were considered: - Direct Ascent: A single vessel, barring lifter stages, would be flown to and landed directly on the Mun, before being flown back to Kerbin. The crew return command pod would itself form part of the lander stage. - Munar Orbit Rendezvous: A single vessel containing the command pod and a separate lander would be flown to the Mun, where the lander would independently land on the surface before rendezvousing with the command pod prior to the return flight to Kerbin. - Kerbin Orbit Rendezvous: Both the lander and crewed command pod were launched separately and docked in Kerbin orbit prior to Trans-Munar Injection. Due to budget constraints and the short notice given to execute the mission, KSA opted to save development costs by using the existing standardized Magnum-K lifter to launch either a KES spacecraft or a dedicated lander, but not both concurrently. Consequently this entailed the use of the KOR architecture. Crew The crew for KES Munar 01 were selected from Kerbonaut Group 1, former Air Force personnel from various Kerbal nation-states2: Major Jebediah Kerman - Mission Commander A former Confederate Air Force combat and later test pilot, Jeb retired from the military after the war, and had (grudgingly) been reduced to selling refurbished Intercontinental Ballistic Missile (ICBM) parts to civilian hobbyists launching sounding rockets. With the establishment of the Kerbal Space Administration, the agency considered his extensive flight experience a vital asset to the fledging space program, and thus he subsequently gained the distinction of being the first Kerbonaut to go into space. Captain Bob Kerman - Command and Service Module (CSM) Pilot Once mentored by Jeb in the later years of the war, Bob clocked an impressive number of flight hours in his KF-47 Ravenspear Interceptor, despite never seeing any action. He was quickly snapped up by the unified Kerbal Federation Air Force after the war to help evaluate various hardware previously used by the various absorbed former Kerbal nation-states, but was quickly relieved of his duties due to excessive snack consumption resulting in aircraft undercarriages collapsing under his weight. Initially recruited by the KSA as a stand-in whilst they searched for Jeb, the agency decided to keep him anyway after the infamous "Photocopier incident". Lieutenant Bill Kerman - Munar Lander Pilot / Flight Engineer The oddly quiet and mysterious of the trio. All that is known about Bill's past was that he was one of the junior engineers under Wernher von Kerman when the latter convinced the Confederacy during the war to mass-produce his surface-to-surface missile designs - they very precursors to the ICBMs that ultimately cost Jeb his job as a pilot. Has a penchant for repeatedly reseating fuses in electrical distribution panels whenever no-one's looking. Mission Highlights Outcomes - Successful manned landing on Munar surface 2.4 km east of planned landing site - Munar EVA duration: ~6 hours - Munar sample mass total: ~12 kg - Longest distance traversed by foot on Mun: 2.3 km by Bill Kerman - Highest unpowered jump from surface of Mun, ~3 m by Jebediah Kerman - Kerbal Munar Rover repaired and recommissioned - Successful crew and Munar sample return to Kerbin Recommedations for Future Missions - It was noted that the Magnum-K upper stage hastily reworked as the Trans-Munar Injection stage was not able to be fully-refueled while in Kerbin orbit. While the KES spacecraft and the docked lander were successfully boosted into a stable lunar orbit, the injection stage quickly ran out of fuel before the orbit could be properly circularized. It has been suggested that a dedicated third stage with a LV-N Atomic Rocket Engine be added to the stack for use in the actual Trans-Munar Injection, or the Magnum-K upper stage's Rockomax LV-909 "Poodle" Liquid Fuel Engine be retrofitted with said atomic engine. In general, highly efficient engines would be a vital part of transfer stages for Trans-Munar or Interplanetary flights. - Perhaps the greatest deficiency was in the Munar Lander, which was found to lack the neccessary fuel reserves to fully circularize its ascent orbit, even with the added external LFO tanks, neccessitating an emergency rendezvous by the KES spacecraft as well as burning all the Lander's RCS reserves to extend the duration of the latter's own suborbital trajectory. An upgraded Munar lander would be required to be able to land from, re-ascend and circularize to an altitude of at least 200 km above the Munar surface, with at least 20~30% fuel reserves for rendevousing with any KES in Munar orbit. - Remedying the fuel and thrust deficiencies with the Injection and Lander stages should leave the standard KES spacecraft's fuel reserves untouched unless in dire emergencies. - A further possibility would be to convert Munar resources into rocket fuel to top-up the Lander's own reserves. Days after the return of KES Munar 01, the Extraplanetary Sciences working group3 have announced the discovery of a liquid substance contained within the subsurface of the Mun, tentatively dubbed "Kethane", through the reconfiguration of Kerbal Munstar 1's Gavitational Distortion Meter. Laboratory experiments have confirmed that the compound, which naturally occurs on Kerbin in very rare quantities, can be satisfactorily converted into LFO. Extraplanetary Sciences have, in conjunction with the Exploration Gateway working group3, proposed the construction of remote surface facilities to extract and convert Kethane into LFO, as well as a small orbital outpost in the Mun's SOI to receive and store the produced rocket fuel from unmanned tankers for refueling landers. The outpost could additionally act as an orbital staging area for crew leaving or returning from the Munar surface, and as a quarantine facility. 1Equivalent to June in the Human Gregorian Calendar System. 2Kerbal unification occurred in mid-KY497, following a decade-long global war between major factions led by the Confederacy, Krussian People's Republic and the Honko Hegemony that ended in mutual devastation. 3Subdivision(s) of KSA, much like JPL is to NASA Mods Used - SQUAD Panopticon Cupola modified to house three Kerbals (in lieu of an as-yet hypothetical proper replacement FusTek mod part ) - MechJeb: Primary guidance computer for all stages of flight - KSPX: LFO fuel tanks for Lander, Z-1K Battery for Magnum-K unmanned payload lifter variant, Escape tower for KES - KW Rocketry: Aerodynamic fairings - B9 Aerospace: Fuselage adapters, lights, Atlas low profile engine for Lander - Lionhead Aerospace: Circular Solar Panels - Supernovy's Advanced Service Module - DeadlyReentry: Heat shields only for visual accuracy; the actual heat damage plugin was not used

I thoroughly enjoyed reading your mission reports, as there was a clear procession from early orbital flights to planetary landings and space stations (a la Mercury->Gemini->Apollo->Skylab). Nice use of the FusTek Station Parts Expansion, too

Did you try downloading the unofficial R0.02.2a DEV BUILD? Also, what mods are you using?

I confirm that this fix works - thanks!

Now that I think of it, I believe I can easily make such a variant for R0.03a - let's call it the "Kuest Legacy Airlock", and I'll put something in the description about being rated for space-only operations / lacking decon facilities. It will share the same IVA as the primary Kuest design, though. Correct. Originally, I wasn't going to put EVA hatches on any of the Karmony modules because I expected most folks to use Kerbal Crew Manifest. However, I realized that for those not using said mod may accidentally trap Kerbals inside the modules prior to launch, so I still had to put one somewhere. In lieu of fusty's side-mounted "escape" hatch design (which I didn't like), I assigned the top hatch on all modules to have this functionality because it was a common and consistent location. While Kerbals could enter and exit freely under this arrangement, I found that apparently if the EVA hatch was more that 1m away from the CoM (as was the case with my 3m+ modules), the collision meshes for the airlock would not properly detect obstructions, hence the dreaded explosion-on-EVA bug. Shifting the mesh and attachment nodes so that the top hatch was closer to the CoM solved this issue. Now, you won't see this in other crewed modules made by SQUAD or other modders because the EVA hatch is always within 1m of the CoM. I too had quite a bit of a struggle dealing with wibbly-wobbly modules atop of my lifter, so like you I would use Quantum Struts, or simply limit the size of each component I lift into orbit. Ah, cheers for that

You can easily reproduce said observation by adding a shielded docking port to the top of the stock Structural Fuselage. Believe me, what has been seen cannot be unseen. Have brain bleach within arms' reach.

I've noticed a minor peculiarity with MechJeb and Romfarer's missiles: Issue: Missiles may automatically fire when installed on a craft with MechJeb Reproducing the issue: Add both MechJeb 2.0.8 and Romfarer's Lazor Guided Missiles into KSP Modify all command pod configs to use MechJeb Attach missiles to any vessel, staging them individually and separately from any engine stage Scenario 1 - Using spacebar to activate engines of initially launches craft - Moments later and without any user intervention, missiles automatically fire Scenario 2 - Map engine toggling to action group key - Use action group key to activate engine - Moments later and without any user intervention, missiles automatically fire Current Workaround: According to a post in the Lazor System thread, if MechJeb is present and auto-stage is enabled under Ascent Guidance, the missiles would auto-fire (even if the Ascent Guidance module is not enabled for the current vessel). Untickingauto-stageallows missiles to be launched manually.r4m0n, do you think you might be able to look into why auto-stage is (apparently) active even if its parent Ascent Guidance module is disabled?

Progress Report, 6 July 2013 Next on my to-do list for R0.03a was the Docking Module, tentatively dubbed Kirs (after the Pirs Docking Compartment on the real-life ISS): Fig 20 - (WIP) FusTek Kirs Docking Module Kirs is intended for use on larger, more crowded space station configurations where large spacecraft and spaceplanes with recessed docking ports may have difficulty docking with the relatively bulky ends of the standard 2.5m diameter modules. The aforementioned issue is thus addressed by having instead a narrower monolithic 1.25m diameter compartment to act as a standoff between the oversized craft and the rest of the station. In modelling the Kirs, I settled on a single non-tapered design, as having a version with the taper may cause trouble with the standard 1.25m-sized crew-accessible docking ports* (stock Clamp-o-tron, fusty's CBMs). This also enforces visual consistency with the hatches on the other FSPX modules. Needless to say, Kirs looks nothing like the real Pirs Docking Compartment, as the latter has a heavy Soyuz/Progress (Russian) flavour. I simply liked the way the name sounds. The WIP as it stands is fully functional in-game (EVA ladders, top hatch designated as emergency airlock). However, I'm tempted to improve on the model by adding: - EVA handle ring at both ends - Cosmetic greebling, such as miscellaneous external equipment boxes, docking guidance sensors etc - Attachment nodes for folks to attach robotic arms (e.g. Romfarer's Canadarm/Buran arms, nothke's DROMOMAN) for berthing *Just now, I discovered to my delight (followed by sheer unbridled horror) that the WIP Kirs fits very nicely with the shielded docking port, both structurally and aesthetically.

Progress Report, 5 July 2013 Something requested a while back, which I've knocked together quickly: Fig 19 - FusTek Karmony Node Covers - Final Testing These plain structural plugs will transform any Mk III Node into Tee and various other junctions. I've done a (reasonably) good job of lining up the FusTek panelling, and any discrepancies in the mesh are due to the optimizations required to avoid the dreaded VAB/SPH lag. A variant with an integrated viewport will also be included in the next release. It was suggested that these plugs be removable / reattachable via KospY's Kerbal Attachment System - if anyone figures out how to implement said capability such that the plugs can be accurately reattached in EVA over the Mk III Node recesses, I'll definitely add your CFG code into the official FSPX release (with attribution, of course).

As someone who is more competent in parametric CAD software like SolidWorks (as a consequence of my BE degree), I speak from personal experience that geometries drafted in engineering-oriented CAD convert very poorly in mesh-based modelling software like Blender, 3DS Max and Maya. The amount of work required to draft the initial geometry in AutoCAD, import into Blender and optimize it/fix mesh errors in far, far greater compared with just natively working in Blender alone. There are numerous Blender tutorials on the 'net, and personally it took me around three months to learn Blender from scratch at a very leisurely pace - I can now fairly easily make complex geometries and UV unwrap texture maps all by myself (I'm less competent in making the actual textures match the SQUAD aesthetic, but that's probably a Photoshop-related skillset).

Harsh, man. Very harsh.

I gave this request a long and hard thought. Bear in mind that these modules are primarily intended for use in space stations and planetary outposts, rather than rocket / spaceplane fuselages - Mecha Pants' interplanetary spacecraft range is the exception rather than the norm - so this parts pack will focus on the former rather than the latter. And while I understand what you mean about the 120° opening in the Wayland cargo bay, the final iteration of the Warehouse module (R0.04a? R0.0Na?) will have a even smaller two-door opening of just 90°, so that my own bay doors won't collide with neighbouring modules. A rotating postcard stand-like assembly would allow Kerbals to rotate the desired rack inside the Warehouse in and out of view. RoboRay's SpaceJunk Cargo Bay would probably better fit your needs - if you insist, you could always dress them up with my Karmony End Rings and Bulkheads.

Progress Report, 2 July 2013 And we're back to my (irregularly scheduled) WIP updates, this time with something I'm working on for R0.03a. Fig 18 - FusTek Karmony Parts Warehouse Modules - Final Testing I'm quite fond of the OrbitalConstruction Redux mod, which allows players to build spacecraft in the VAB and launch them directly from a spacedock in orbit. However, I restrict my use of said mod for constructing items that cannot be feasibly contained within KW Rocketry aerodynamic fairings for standard launches, such as: - Interplanetary spacecraft - Oversized rovers - Complex closed-loop truss segments for space stations - Large solar arrays OrbitalConstruction uses two types of containers filled with spare parts (one type for ferrying limited amounts into orbit, the other for actually storing them), which are currently repurposed stock fuel tanks. As such, I've devised my own version that fits the FusTek aesthetic, each of which will be able to hold up to 200 units of parts. Since they're simply part storage, these modules will not hold / allow passage of crew, and will not have IVAs. However, I do intend to further modify these to use nothke's WIP KASPAR payload rack system, so that Kerbals could replenish batches of parts manually through EVA, for added realism. So when these come out in R0.03a, please avoid obstructing / surface attaching anything to the side of the module where the bay doors will be located in the future.

No worries

Those sliders are hawt, sirkut. Will they by any chance be modular? (i.e. any length of rails can be connected together to form longer / more complex segments)

Looking great so far, tek_604 - the idea of sample collection and return mission has great potential as it give players setting up planetary space stations and outposts actual goals to accomplish. I recently wrote a (long) post on sample collection/analysis/return in general and how the former could be interwined with resource extraction/processing/storage - so that I'm not derailing the current discussion, I'll just leave the following link for people who are interested to read at their own pleasure: http://forum.kerbalspaceprogram.com/showthread.php/38087-Musings-on-Resources-and-Sample-Collection-Analysis-Return In particular, I'd like to point out the specific idea that sample return to Kerbin should only be required if a sample contains an unknown or rare compound - otherwise, in-situ analysis and reporting of results will suffice for more common substances.