-
Posts
4,257 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Everything posted by sumghai
-
I experimented with parallel docking (i.e. two or more points of contact between vessels) via MechJeb the other night, as part of a series of test runs for constructing my space station. Of the two "vessels" involved: - One was a segment of Semni's THSS trusses, with two docking ports on the bottom face - The other was a pair of FusTek Mk III space station nodes, connected lengthwise and also with two Clamp-o-tron docking ports attached radially and facing the same side 1 2 ===∨===∨=== truss ===∧===∧=== space station modules 3 4 (Do excuse my lousy ASCII art) I started by taking control of the truss (it had a probe part) and set docking port 2 to connect with docking port 4 on the modules. I then quickly switched flights to the modules and set port 3 to dock with port 1 on the truss. With both vessels running the Docking Guidance system simultaneously, they eventually wobbled their way towards each other via RCS and docked perfectly at both points.
-
Perhaps, although either way the Kupola will still be relegated to R0.03a. The bulkheads are cosmetic structural elements that make the ends of fuel tanks look nice That, good sir, is one sexy spaceplane. B9 Aerospace pack I presume? I'll probably leave it up to other modders to write their own missions with the ModuleManager DLL, since I'm more of a sandbox-mode type of guy.
-
I'm relegating the Kupola Observation Module to R0.03a, because of the amount of work required: - IVA - this'll be my first go at interiors, so this would be a major challenge in itself - See-though viewports - Kerbals working in the Kupola will be viewable, and correspond exactly to what is in the IVA view (i.e. no Kerbals in IVA = no Kerbals seen from outside) - Animated blast shutters for the viewports - although the real ISS Cupola has bulky hinged panels, I feel that sliding ones on the sides and an iris at the top would better fit the Kerbal / FusTek aesthetic
-
Progress Report, 16 June 2013 Polishing off some new parts for the next release (Date TBA). First up are the 2.5 m bulkheads, that magically transform any appropriately sized fuel tank or whatnot into a FusTek-compatible module. They're also compatible with the tapered end rings already available in R0.01a: Fig 14 - FusTek Karmony Bulkhead - Final Testing Next up, two upcoming mission-specific variants - the Utilities and Science module(s). Each will come with their own Module Identifier Symbol and toggleable window lights (thanks to some choice tips and tricks from Lack): Fig 15 - FusTek Karmony Utilities Module - Final Testing Fig 16 - FusTek Karmony Science Module - Final Testing The Utilities Module is intended to act as the "core" module of any space station / planetary outpost - with this in mind, it has higher than usual amounts of power (150) and monopropellant (180) capacity, and will also come with native RemoteTech RemoteCommand support (crew not essential). I may also throw in Chatterer for good measure as well. The Science Module will be where Kerbals conduct various experiments (e.g. analyzing rock samples from planets). If and when Squad or other modders add more meaningful scientific features to the game, the science module's CFG will be updated accordingly. Some behind-the-scenes tweaks include: - Lowering the monopropellant capacity of most modules from 180 down to 100. There should still be plenty for occassional orbital corrections / dockings. - Finalized crew capacities for each module - Node Mk III: 2 - Logistics Module: 2 - Science Module: 4 - Utilities Module: 2 - Kuest Airlock: 1 - Switched to using compressed TGA textures, as Unity apparently has a bug that loads the original PNG images much more slowly The only module missing for R0.02a is the Karmony Habitatation Module, which will come with certain challenges: - The placement of viewports will be directly affected by the hypothetical interior layout - If possible, I'd like to try making viewport window lights individually toggleable (e.g. GalleyLights, SleepStation1, SleepStation2, SleepStation3, SleepStation4) Luckily, I've already reproduced the basic Karmony module model in SolidWorks, and have already determined some key habitable dimensions - the next step would be to translate those measurements into various volumes, and block out the various compartments within the Hab module, which would help window placement. Once again, IVAs will be left until R0.03a / R0.04a, when most of the module externals have been finalised.
-
Thanks again, Lack - my part now retains the Blender/Unity prefab connection, while the animation can still be configured in Unity / played in-game. In my particular case, I had a mesh in my model hierarchy dubbed "viewport_1" - in the original situation described in my last post, I would not have been able to open the materials instance in the animator. However, using a slight variation of Lack's workaround, I dragged viewport_1 from my main hierarchy to a position just below the corresponding item's materials instance in the animator - this has the effect of "forcing" drop-down icon open. I suspect this is a minor bug with Unity, but at least there's a workaround for it now.
-
Mucho gracias, Lack - I managed to implement the lighted windows after a few hours of head-scratching. Some extra tips/observations for those who may come across this thread: 1) [iGNORE - See Lack's workaround] Make sure your meshes are *direct* children of the PartTools GameObject in Unity's Hierachy As a Blender user, I had the habit of directly dragging my .blend file under the aforementioned GameObject to import my meshes, resulting in the meshes being grandchildren (i.e. GameObject > *blender_filename* > desired_meshes). While this usually worked for most of my parts, I found that the nested hierarchy would prevent you from expanding the materials you wish to animate for the emissives. The solution is to manually drag the meshes directly under the GameObject itself (i.e GameObject > desired_meshes), which allows the animation properties in the parent GameObject to actually be able to access the desired meshes. Note that this does break any prefab connections between Unity and Blender, so if you make any changes to the mesh / UVs in Blender, you'll have to manually reimport your model(s). 2) Part windows lit in VAB/SPH part preview thumbnails list? Here's the solution I've noticed that in Lack's canopy windows, when the part is previewed in the VAB/SPH part thumbnails list, all the windows are lit (although actually dragging the part out into the building area results in the expected dimmed windows). I suspect that the parts preview shows the model in its final end-of-animation stage. If you're a stickler like me and want the part preview thumnails to also show dimmed windows, then define the initial alpha value of the emissive color to 0, and have the animation keyframes change it as usual - this will dim the lights in the thumbnail, but you'll still be able to toggle and animate the lights as normal during flight. (PS If someone could verify my observations on their own setups, that would be great)
-
As do I, and I second Devo's notion.
-
I'm relatively new to the KSP part modding scene, although I have managed to create some station modules with (reasonably) working airlocks and EVA handles. My next challenge is lighted windows toggleable in-game, similar to what Lack of LLL and udk_lethal_d0se have on their parts. How would I go about implementing this - are they animations with emissives, or something else?
-
That's unusual - I have a ****ty 2005 laptop that runs these parts reasonably well. My meshes are actually rather low-poly - 24 sides per cylinder and combinations of simple cuboids for EVA handles. The detailed panelling are actually normal image maps. I think the problem may be my use of PNG rather than compressed TGA / MBM textures - apparently Unity has a PNG import bug that may be causing this issue. I'm definitely transitioning to TGA / MBM textures in my next release, so hopefully that would fix your problem.
-
You're supposed to look for the blueprints on the internet yourself and model accordingly from scratch. People here will help you understand the finer nuances of KSP, but making 3D models is something you need to learn yourself.
-
I believe that crasher is attempting to get the NX-01 into KSP, which wouldn't use the TOS NCC-1701 bridge.
-
At the outset, my inclusion of such copious of monopropellant was intended to help with station-keeping, orientation and some somewhat decidedly unorthodox docking manoeuvres*. That said, I definitely agree that I should tone them down across the board, though. *ASIDE: Last night, I was experimenting with simultaneous multi-node docking - I had a length of THSS trusses with two side docking ports corresponding to a similar arrangement of ports on two Mk III Nodes connected lengthwise. I set both craft to dock towards each other via MechJeb2, and managed to get a solid connection at both locations. Righto. Stock RTGs have a rate of 0.75 units per second. How would 5 or 10 units per second sound for the Karmony Utility Module? Moon Goddess: Although Squad's current IVA view is limited to the seated posture, I'd love to be able to make one strapped inside a sleep station, and the other three sitting around the mess table. Archer: Yet another excellent observation, good sir. My original intention would be to have the Kerbals in sleeping bags velcroed upright against the walls, for the following reasons: - It's what real astronauts do on the ISS - Velcro seems very Kerbal-y - Vertical sleep stations would allow me to put viewports on the outside hull Horizontal sleeping positions do seem more sensible in a >0g environment, although window placement could be problematic. I'm also thinking of rearranging my mockup to somehow wedge the toilet and shower stations vertically between bunks. I'll have to try stuff out in SolidWorks later today. The bright white panelled aesthetic is to ensure consistency with fusty's original Mk II parts, and although it does look slightly out of place amongst all the rough-and-ready stock parts, I've grown quite fond of the Fustek aesthetic.
-
My experience with optimization plugins has been mixed. As someone with an engineering background, I was more familiar with parametric modelling in SolidWorks and Pro/Engineer, so I made my first models there and imported them into Blender. Unfortunately, even with native or plugin optimization scripts the final meshes were still very difficult to work with / UV map. Ultimately I sat down one day and watched a 30 minute Blender tutorial, and Googled other tips and tricks after that. It didn't take me too long to learn Blender enough to make decent models for KSP (as evidenced by my FusTek Station Parts Expansion). crasher needs to learn to do things from the ground up, like modelling basic geometry, extrusions, rotations, scaling, mesh dissolving, etc. He can't learn anything if he just grabs other people's models and run them through a magic black box. Doug Drexler himself would probably agree with you.
-
crasher, I've got a number of serious peeves regarding you ripping models from TrekMeshes.ch: - As WCOLE360 has stated, simply taking other people's models and redistributing them without their permission constitutes stealing / swiping. - The meshes on the website are all designed specifically for very high-quality still renders or animations. TV show levels of detail would be far too much for KSP to handle, so it is much better to learn to remake the model from scratch yourself in Blender, where you can balance detail and performance. (For instance, Star Trek Online's ship models have fairly low poly counts, to optimize in-game loading) Modding requires plenty of time, patience and skill. Don't take the easy way out and cheat.
-
Some lesser-known bits of info for addon developers
sumghai replied to NovaSilisko's topic in KSP1 Mod Development
Looks like I'll have to switch from PNGs in my next release. -
Hmm... A folding truss is probably too much of a challenge for me - I myself am rather fond of Semni's THSS trusses, due to their lightweight strut-like design and variety of adapters/accessories. I have some thoughts on EVA-erectable trusses (and orbital construction in general) that would be best left for another thread. Progress Report, 11 June 2013 Barely hours after successfully posting R0.01 Alpha to SpacePort, I've started working on the next batch of crew-capable modules: - Karmony Utility Module - Karmony Science Module - Karmony Habitat Module These will be the first to feature light-up windows to add interest to space stations and planetary outposts, although they will have a cooler (whiter) color temperature compared to those in Lack's LLL parts, since I consider the former to be more realistic. I've also been thinking more about what capabilities / resources to put into each of the crew-accessible modules; some of these are already implemented in the R0.01A release, although I have yet to finalize them. I'm rather apprehensive about including life support at this stage, since I'm sure most of us have our own ideas as to what resources people would want to deal with. Karmony Node Mk III CrewCapacity = 2 (While there may be room for at least six like in fusty's Mk II nodes, I personally think there are not supposed to be seats in what is ostensibly a junction that would see high foot traffic) ElectricCharge = 100 MonoPropellant = 180 MechJeb2 Karmony Logistics Module CrewCapacity = 2 (Again, since this is technically a corridor lined with storage bins, Kerbals would want to just grab their packed lunches and get going) ElectricCharge = 100 MonoPropellant = 180 MechJeb2 Kuest Airlock CrewCapacity = 1 (The airlock has storage for two EVA suits, as well as a separate lockout/decon chamber. However, it'd be sensible that the only one Kerbal is inside prepping for EVA at a time.) ElectricCharge = 50 MonoPropellant = 90 (Might remove this, as the Kuest is intended as an add-on rather than an independently flyable unit) Karmony Utilities Module CrewCapacity = 2 (Two Kerbals ought to be enough to periodically monitor station operations from here) ElectricCharge = 150 MonoPropellant = 180 MechJeb2 RTG? (Small power generation with limited capabilities - most of the time people should be building solar panel arrays or separately detachable RTG banks) RemoteTech? (As the "core" of any space station, the Utilities Module should probably have communications / telemetry capabilities) Karmony Science Module CrewCapacity = 4 (Located at various science stations) ElectricCharge = 100 MonoPropellant = 180 MechJeb2 Karmony Habitat Module CrewCapacity = 4 (Corresponds to maximum number of wall-mounted sleep stations, but actually seated around mini dining/conference table) ElectricCharge = 100 MonoPropellant = 180 MechJeb2 Kupola Observation Module CrewCapacity = 2 (Seated and facing sideways rather than up) ElectricCharge = 50 (Lander variant will be released in a separate parts pack)
-
One of my fundamental design goals was to get rid of the emergency hatch that was present in the Mk II, and instead reassign the airlock to an existing hatch. I chose the top one (or more correctly, the fore hatch) since that location is consistent across most modules. It was also intended that people would use Kerbal Crew Manifest to transfer crew between modules, in lieu of official IVA navigation, so that stacking modules should not matter. I should probably update the Release Notes and Dependencies to state this fact, but otherwise, this is technically working as intended.
-
Apologies for the confusion. At present, the Karmony modules come with integrated MechJeb2 support, allowing people to operate them without any Kerbals. However, I'm definitely planning on adding true RemoteTech support to one of the modules in the next release (specifically, the Karmony Utilities Module) - if there's anyone familiar with the functionality of RemoteTech, I'd be happy for them to help experiment with various configurations.
-
Development of this add-on is on hold until further notice. In the meantime, feel free to play around with my current dev build on GitHub. I'll reopen this thread at a later date. ISS-inspired habitation, science lab and other crew compartments for building space stations and planetary outposts. A continuation of Alex "fusty" Sterling's original work. Dependencies - ModuleManager (sarbian), for applying patches for functionality/features provided by dependencies and third-party add-ons - RasterPropMonitor (Mihara / MOARdV), for making transparent "look-inside" station module windows and (in the future) full RPM MFD capabilities - Ship Manifest (Papa_Joe) and Connected Living Spaces API (codepoet), to allow the transfer of crew between station modules without the use of hatches or EVA Supported Third-Party Addons - Deadly Re-entry Continued (NathanKell / Starwaster) - if installed, all station modules and associated parts will burn up during atmospheric re-entry if not shielded properly - Firespitter V7.1.x (Snjo) - if installed, all station modules and associated parts will have the option of using alternative texture packs - Kerbal Inventory System 1.1.5 (KospY) - if installed, inventory slots will be added to selected station modules and the Node module side recesses will be retrofittable with Node Covers / docking ports - Modular Fuel Tanks v5.0.3 (taniwha) - if installed, the Resupply module will gain a reconfigurable propellant storage tank Reconfigurable propellant storage tank will be migrated to a new part - TAC Life Support (TaranisElsu) - if installed, will add varying life support provision storage / resource processing capabilities to selected station modules Download - GitHub Repo (alternatively, the direct download of the current experimental WIP build) - CurseForge (Last stable version, X0.04-4 DEV BUILD / 5 June 2014) Will be back when V1.0 is ready How To Install 1. Ensure that you have all of the aforementioned dependencies installed 2. Remove any previous version of the FusTek Station Parts add-on 3. Download from one of the sources above 4. Extract the .ZIP archive and copy the GameData folder provided into your KSP root directory The parts should then be located under the FusTek/Station Parts folder Usage - Most of the provided parts are crew-habitable modules that can be used for building space stations or planetary outposts, and come in both flat 2.5m and tapered 1.25m variants. - Karmony Utilities Modules are essentially the "core" module of your space station or planetary outpost, and can be operated with or without Kerbal crew. - The FusTek Resupply module is essentially a large probe core designed to be reconfigured by users for carrying supplies to and from stations. - Only the Kuest Airlock and Kuest Legacy Airlock permit EVA. Movement between other modules requires both the Ship Manifest and Connected Living Spaces (CLS) plugins. - Structual end rings included in the pack can transform a flat 2.5m module into its tapered 1.25m version, or allow two or more modules of different types to be combined together as one monolithic "extra-length" module. - Bulkheads converts any 2.5m fuselage or fuel tank into ones that match the FusTek aesthetic, and are also compatible with the end rings. - Special docking ports (IACBMs) come with built-in lights, animated guidance fins (cosmetic, non-functional) and an option to retrofit the signature FusTek yellow-bordered hatches onto non-FusTek crew compartments / pods - Alternative texture packs such as MLI Blankets (InsaneDruid) and KSO Phase II (SippyFrog) are now included by default; their respective authors have agreed to push further updates to their pack directly to the main FusTek repo, so that you will always get the latest compatible version. Due to some clever MM patch writing by InsaneDruid himself, these texture packs can be individually removed by deleting their respective subfolders, without the need to edit any CFGs files yourself. Uninstallation Instructions Remove the FusTek folder and all its contents from the GameData folder. If you have other FusTek part packs you wish to keep, just remove the Station Parts subfolder. Need Help? Please read the FAQ at the bottom of this post first, as it addresses common issues and their solutions/explanations. If your issue isn't covered by the FAQ, post your bug reports and support requests in this thread, providing as much information as possible (error logs, screenshots etc.) Licence This parts pack is licenced under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0), which in layman's terms means: - You are permitted to use, copy, redistribute my work as-is - You may remix your own derivatives (new models, alternative textures), and release them under your own name - You must credit Robin "sumghai" Chang and Alex "fusty" Sterling (author and original author, FusTek Station Parts) when publishing your derivatives in the download and forum posts Further Information - Development thread (Behind-the-scenes, preview of upcoming features) Release Notes Experimental Builds Live via GitHub early-to-mid 2015 --------------------------- Features, bugs and known issues are described in the repo's issue tracker. X0.04-4 DEV BUILD 5 June 2014 --------------------------- Features: - New Parts - Karmony Payload Bay Module - Karmony Payload Bay Module Adapter - The Payload Bays are genericized variants of the Warehouse module that will be designed without the rotating payload rack magazine - Deadly Re-entry Continued support added - All FusTek parts will burn up during atmospheric re-entry (specifically, above 800°C) - If you're planning on building surface bases on Duna and Laythe, be sure to install heat shields properly - A Module Manager config, FusTek_MMPatch_DeadlyReentry.cfg, can be found under GameData\FusTek\Station Parts\Parts\MM_configs, and is used to define maximum heat tolerances for all FusTek parts - TAC Life Support integration finalized - Each module will have varying amounts of crew provision / waste storage tanks and resource processing capabilities, depending on their intended purpose - A Module Manager config, FusTek_MMPatch_TACLifeSupport_ModularFuelTanks.cfg, can be found under GameData\FusTek\Station Parts\Parts\MM_configs, and is used to define life support resource quantities for each FusTek part - The FusTek Resupply Module is now pre-configured to carry both life support crew provisions and various types of spacecraft fuel for resupplying space stations / planetary outposts - Crew provision quantities can be altered using the stock KSP tweakables system - Varying combinations of LiquidFuel/Oxidizer/Monopropellant/Xenon can be filled using Modular Fuel Tanks, up to a maximum total mass of 800 kg Changes: - Crew habitable modules now have unique IVAs - At present, they are only used to test layouts and crew seating positions - Karmony Utilities Modules can now hold up to 500 units of ElectricCharge - Some Karmony module viewports have been repositioned to match up with the WIP internals - Kirs Docking Module hatches have been resized to match up with the WIP internals - Inner bay textures for Karmony Warehouse and Payload Modules finalized Fixes: - Kuest / Kuest Legacy Airlocks will now store science reports acquired from EVA - Alternative texture switching now supports multiple objects with the same name on the same part - This requires the experimental v6.4 pre-release of the Firespitter plugin Issues: - IVAs are still a work in progress - Models and textures are placeholders - RasterPropMonitors are not yet implemented - KSO Phase II Alternative Textures have not been updated to coincide with changes / new parts - That's Sippyfrog's responsibility, not mine :P - Warehouse has incomplete functionality - Work will on this will continue in R0.05a X0.04-3-1 DEV BUILD Hotfix 11 May 2014 --------------------------- Fixes - Compatibility patch for Connected Living Spaces 1.0.4.1 update - Specifically, adding "passable = true" to the Kuest Airlocks and Kupola X0.04-3 DEV BUILD 24 April 2014 --------------------------- Features: - Modules now (tentatively) support alternative texture packs - These can be placed under GameData\FusTek\Station Parts Expansion\Parts\AltTexturePacks - A Module Manager config, FusTek_MMPatch_TextureSwitch.cfg, can be found under GameData\FusTek\Station Parts Expansion\Parts\MM_configs, and is used to define custom texture sets for each FusTek part - A sample implementation of Sippyfrog's "KSO Phase II FusTek Retexture" is included for reference - Connected Living Space (CLS) integration finalized - Parts that can hold crew and are traversable: - Karmony Habitation Module - Karmony Habitation Module Adapter - Karmony Science Module - Karmony Science Module Adapter - Karmony Utilities Module - Karmony Utilities Module Adapter - Kirs Docking Module - Kuest Airlock - No access via top node, as that is where the external airlock door is located - Kuest Legacy Airlock - No access via top node, as there is no hatch object there - Kupola Observation Module - No access via top node, as that is where the main viewport is located - Parts that cannot hold crew, but are traversable: - IACBM 1.25m - IACBM 2.5m - Karmony Bulkhead - Karmony compactNode Mk III - Karmony compactNode Mk III Adapter - Karmony End Ring - Karmony Node Mk III - Karmony Node Mk III Adapter - Karmony Logistics Module - Karmony Logistics Module Adapter - Parts that are not traversable under any circumstances: - Karmony Node Cover - Karmony Node Cover - Viewport Variant - Karmony Warehouse Modules - Karmony Warehouse Modules Adapter - FusTek Resupply Module - A Module Manager config, FusTek_MMPatch_ConnectedLivingSpaces.cfg, can be found under GameData\FusTek\Station Parts Expansion\Parts\MM_configs, and is used to define CLS settings for each FusTek part Changes: - All parts, models and KSP internal names have been changed to ensure compatibility with dependencies such as Firespitter and CLS - WARNING: This is a craft-breaking change! Issues: - Alternative texture switching isn't 100% functional, - Firespitter plugin currently cannot update multiple objects sharing the same name - Snjo is already aware of this and is working on a fix - Warehouse has incomplete textures and functionality - Work will on this will continue in R0.05a - IVAs are still a work in progress - For now, most will borrow stock KSP internals X0.04-2 DEV BUILD 11 April 2014 --------------------------- Features: - New Parts - Karmony compactNode Mk III - Karmony compactNode Mk III Adapter - FusTek Resupply Module - The compactNode Mk IIIs are six-way nodes that area approximately half the length of the standard Node Mk IIIs, ideal for crowded station designs - The FusTek Resupply Module is essentially a oversized probe core that users can reconfigure to carry whatever resources they need for station resupply Changes: - Compatibility Patch for KSP 0.23.5 - Removed FusTek_Sumghai.dll plugin - This parts pack now has Firespitter.dll as a dependency, which is more regularly updated and supports tweakables - Reworked common texture atlases to 4096 x 4096 px - The updated UV island maps will now allow non-tiled alternate textures - Also removed ENG TEST ARTICLE watermarks - Texture switching will be supported in a future release - Removed airlock functionality from majority of crew-habitable modules - Modules affected: - Karmony Node Mk III - Karmony Node Mk III Adapter - Karmony Logistics Module - Karmony Logistics Module Adapter - Karmony Habitation Module - Karmony Habitation Module Adapter - Karmony Science Module - Karmony Science Module Adapter - Karmony Utilities Module - Karmony Utilities Module Adapter - Kirs Docking Module - Kupola Observation Module - Kuest Airlock and Kuest Legacy Airlock will retain said functionality for obvious reasons - Shifted part origins of majority of modules back to 0,0,0 and removed CoMoffset hack - WARNING: This is a craft-breaking change! - Modules affected: - Karmony Node Mk III - Karmony Node Mk III Adapter - Karmony Logistics Module - Karmony Logistics Module Adapter - Karmony Habitation Module - Karmony Habitation Module Adapter - Karmony Science Module - Karmony Science Module Adapter - Karmony Utilities Module - Karmony Utilities Module Adapter - Removed crew-carrying capacity and IVAs for selected crew-habitable modules - Modules affected: - Karmony Node Mk III - Karmony Node Mk III Adapter - Karmony Logistics Module - Karmony Logistics Module Adapter - These modules are essentially junctions and passegeways, have no seats and are thus not intended for long-term occupation - Connected Living Spaces (CLS) API will be supported in a future release - Removed RocketParts capacity from Karmony Warehouse Module / Karmony Warehouse Module Adapter - Official support for OrbitalConstruction and all forks has been terminated; Users will need to apply their own ModuleManager configs at their own risk - IACBM 1.25m / IACBM 2.5m - Removed hatch mode toggle as most FusTek modules no longer have airlocks (making the EVA-through capability for docking ports redundant) - Tweaked docking collider to mitigate wobbly docking port issue - Fixed docking port lights by updating spotlight definitions to Unity 4.3 (no more cyan lights) - Custom placeholder IVA added for Kirs Docking Module Issues: - Warehouse has incomplete textures and functionality - Further updates depends on KASPAR/FLEXrack being released - IVAs are still a work in progress - For now, most will borrow stock KSP internals X0.04-1 DEV BUILD 4 November 2013 --------------------------- Changes - Compatibility Patch for KSP 0.22+ - All parts assigned to the Composites node in the R&D Tech Tree - Overhauled and optimized all parts to take advantage of MODEL{} node calls as well as common texture atlases - All crewed compartments also now temporarily use stock SQUAD internals - Proper FusTek internals will be implemented in X0.04-2 DEV BUILD - Renamed Karmony Parts Warehouse Modules to Karmony Warehouse Modules, and revised model - Warehouses now come with animated bay doors, toggleable both when directly controlling the vessel and when on EVA - These are just placeholders; rotating KASPAR rack functionality will come in future updates R0.03.5a 2 September 2013 --------------------------- Fixes - Tweaked Karmony End Ring attachment points to accomodate new IACBMs - Reworked animation toggling behaviour for IACBM 1.25m, IACBM 2.5m and Kupola - The IACBM guidance fin rotary positions and Kupola blast shutters are now also toggleable inside the VAB R0.03.4a 30 August 2013 --------------------------- Features: - New Parts - IACBM 1.25m - IACBM 2.5m - The Improved Androgynous Common Berthing Mechanism (IACBM) is a docking port system designed to be directly compatible with FusTek Karmony modules and any generic 1.25m/2.5m diameter fuselages - Built-in LED illumninators allow long-distance visual identification / orientation marking of target docking ports - LEDS will consume ElectricCahrge and automatically shut down if deprived of power - Active/Passive mode toggles rotate guidance fins to appropriate positions for docking - Recommendation: The target docking port should be set to Passive, while the docking port on the actively-controlled vessel should be set to Active - Hatch mode toggle allows the IACBMs to "unblock" Karmony hatches that are otherwise obstructed, allowing Kerbals to EVA right through them - Remember to switch back to Docking mode for docking; weirdness may occur if docking is attempted while in Hatch mode Changes: - Karmony Parts Warehouse Module stats updated to correspond to latest version of OrbitalConstruction Redux (4.2) - Dry mass is now 2.5t - Maximum RocketParts capacity increased to 1600, in line with RocketParts density reduction. - Warehouse preloaded with 100 RocketParts, which can be replenished by supply missions using the OrbitalConstruction Redux mod - Total in-flight mass of fully-stocked Warehouse will end up as 6.5t, the same as any other Karmony full-length module - The old settings would have resulted in a (ridiculous) 100t warehouse Issues: - IACBM guidances fins don't actually collide - This is due to technical limitations of KSP's ModuleDockingNode at the time of writing, which causes terminal docking sequences to ignore part colliders - For precise rotational alignment, use in conjunction with Sarbian's MechJeb 2 fork. - Transient "Start Deployed" GUI inconsistencies in FusTek_Sumghai.dll animation modules - NOT craft or functionality-breaking, just a little annoying R0.03.3a 8 August 2013 --------------------------- Fixes - Corrected typo in CFGs from breakintTorque to breakingTorque - All parts have been reviewed by our Quality Assurance (QA) department at great expense and at the last minute R0.03.2a 2 August 2013 --------------------------- Changes: - Compatibility Patch for KSP 0.21+ - Karmony series modules and Kupola now use SAS and Reaction Wheels - No change to monopropellant reserves; future releases will include RCS thrusters built into selected modules - Karmony Parts Warehouse Module now uses RocketParts resource, to reflect changes in the OrbitalConstruction Redux mod by its author R0.03.1a 24 July 2013 --------------------------- Fixes - Tweaked CoM of Karmony series modules so that they line up with the part's geometric centre - This should fix the Center-of-Mass balancing issues, especially with MechJeb - No change to actual part origins, though R0.03a 22 July 2013 --------------------------- Features: - New Parts - Karmony Parts Warehouse Module - Karmony Node Cover - Karmony Node Cover - Viewport Variant - Kirs Docking Module - Kuest Legacy Airlock - Kupola Observation Module - Karmony Parts Warehouse Module is designed for use with the OrbitalConstruction Redux mod, and can store up to 200 units of SpareParts - Kirs Docking Module acts as a 1.25m diameter standoff for docking space stations with vessels that are unable to approach closer - Kuest Legacy Airlock is functionally equivalent to the standard Kuest Airlock, but is cheaper and lighter, at the expense of not rated for use on planetary surfaces - Kupola Observation Modules come with animated blast shutters to protect occupants from space debris. Most of the time. - The FusTek_Sumghai.dll plugin, specifically compiled to handle multiple animations per part, is now included in the pack - This was developed with the assistance of Snjo, and uses portions of his Firespitter.dll code Fixes - Tweaked rendering and collision meshes - This should greatly reduce the "freeze-on-drag" issue some users experience in the VAB and especially in the SPH - Model file sizes have consequently been reduced by up to 50% - Reverted to using PNG textures, which reduces texture file sizes and memory usage (according to some users) - Those responsible for sacking the people who have just been sacked have been sacked - Lowered ElectricCharge rate of Utility Modules to 15.0 / min - Older value was far too overpowered and had made Solar panels useless - Newer value now forces players to add their own solar panels and/or RTGs if more than three other modules are connected in the same structure Bugs/Known Issues - All crew-capable modules currently STILL use either the default generic "UniKarmony" or the stock KSP Cupola internal model - Work on module-specific unique internals will begin in the next version (R0.04a) - Karmony Parts Warehouse Module will be outfitted with animated cargo bay doors and internal payload magazine rack once nothke finishes making his KASPAR mod R0.02.2a DEV BUILD 28 June 2013 --------------------------- (Fixes rolled into R0.03a) R0.02.1a BUGFIX 21 June 2013 --------------------------- Fixes - Resolved exploding hatch issue with all Karmony modules - Consequently, part origins / attachment nodes MAY be affected. Backup your persistence/quicksave files and crafts before installing this fix R0.02a 19 June 2013 --------------------------- Features: - New Parts - Karmony Habitation Module - Karmony Habitation Module Adapter - Karmony Science Module - Karmony Science Module Adapter - Karmony Utilities Module - Karmony Utilities Module Adapter - Karmony Bulkhead (2.5m cosmetic structural part) - Karmony Habitation, Science and Utilities modules come with MechJeb2 support and toggleable window lights - Karmony Utilities module come with RemoteTech (RemoteCommand) and Chatterer support, and also has a small RTG for powering small stations / outposts with less than four connected modules (Solar panels will be required for larger structures) - Karmony Bulkhead converts any 2.5m fuselage or fuel tank into ones that match the FusTek aesthetic - Can also be used in conjunction with the Karmony End Ring Changes: - Cost of Karmony module variants and Kuest Airlock increased to 8500 and 2500 respectively - This makes them comparable to the half-sized stock PPD-10 Hitchhiker Storage Container (4000), as Karmony module variants are twice the Hitchhiker's length and (allegedly) use superior construction techniques - Monopropellant capacity in the Habitatation, Science, Logistics and Node modules reduced from 180 to 100 - Original value was considered too overpowered - All models now use compressed TGA textures, due to a Unity bug that causes PNG images to load very slowly - Those responsible for painting all the modules have been sacked - Crew capacities for all modules have been adjusted: - Nodes: 2 Kerbals - Logistics: 2 Kerbals - Habitation: 4 Kerbals - Science: 4 Kerbals - Utilities: 2 Kerbals - Airlock: 1 Kerbal (Unchanged) Bugs/Known Issues - All crew-capable modules currently STILL use the default generic "UniKarmony" internal model - Module-specific unique internals will come at a later date - Karmony Habitation, Science and Utilities modules may have incorrectly-formatted resource outputs/requirements in the VAB/SPH part description - This is due to various KSP internal PartModules not combining nicely in the part description - Part functionality is not affected R0.01a 8 June 2013 --------------------------- Features: - Initial release - New parts - Karmony Node Mk III (4 recessed nodes + 2.5m flat ends) - Karmony Node Mk III Adapter (6 recess nodes + 1.25m tapered ends) - Karmony Logistics Module - Karmony Logistics Module Adapter - Karmony End Ring (2.5 to 1.25m cosmetic adapter ring) - Kuest Airlock - Karmony Nodes and Logistic modules come with MechJeb2 support - Kuest Airlock features C-shaped EVA handle loop, which Kerbals can fully traverse around - Main difference between fusty's Mk II and this pack's Mk III is the removal of the "emergency hatch" from all modules and redesignating the forward hatches as EVA-able Bugs/Known Issues - All crew-capable modules currently use the default generic "UniKarmony" internal model - Module-specific unique internals will come at a later date - Stacked modules may block the forward EVA-able hatches - This is working as intended; use Kerbal Crew Manifest to transfer crew between modules - Occasionally, a Kerbal may break free and cause the modules to explode. This bit is NOT intended and will be fixed to properly obstruct the hatches of modules connected adjacently. - Crew capacity, power and monopropellant subject to further adjustment Frequently Asked Questions (FAQ) Acknowledgements - Alex "fusty" Sterling: Original inspiration - bac9 & Lack: Lighted windows / Spotlights - gracae86: Telescoping blast shutter - Moon Goddess: CoM offset fixes - InsaneDruid and SippyFrog: Alternative texture packs
-
Fantastic stuff KospY - I had hours and hours of fun making cranes and tethered microsats Just something I was wondering, though - I configured certain parts (such as trusses) to grabbable because I wanted to emulate realistic truss construction in space (rather than flying it all up in a ridiculously large rocket). Although your grab and attach system does work, I'm a bit concerned about the lack of accuracy in my placement even with the debug rotation options open. Would it be possible to extend the generic part-grabbing feature to have the option of using the same attachment node system as in VAB / SPH? No doubt it would make EVA construction a whole lot easier.
-
A 1.25m Cupola would be barely enough to fit one Kerbal, associated life support / missing equipment and a hatch - and in hindsight, I'll most likely make one 2.5m Cupola with a tapered face and observation module IVA, and a separate version with a 2.5m flat face and a lander/cockpit IVA anyway. Right now, I'm focusing on putting together various promotional and sample images for the official announcement of the first release.
-
Here's something I tossed together quickly: The "green" version is merely conjecture from your first post in the thread, although if you were to insert logos on certain parts, the most probable color would be a shade of grey similar to the module identifer icons I'm using for the Karmony mission module variants: