[1.0.X - Experimental] [On Hold] FusTek Station Parts (WIPs on GitHub)

[sharpspoonful]

Wait, you mean to say fairings that are meant to enter an atmosphere and slide to a stop? That is awesome.

[sumghai]

Wait, you mean to say fairings that are meant to enter an atmosphere and slide to a stop? That is awesome.

Oops, that was probably a misleading picture.

The proposed SDHI fairings will have to be jettisoned after aerobraking (like with any heat shield), while the module will land via a specially-designed FusTek strap-on parachute / descent rocket kit.

Edited May 23, 2014 by sumghai

[johnwayne1930]

@sumghai

Looking forward to that fairings! :-)

Btw, do you still plan to make the Space Exploration Vehicle some day?

[sumghai]

Btw, do you still plan to make the Space Exploration Vehicle some day?

I still do - it's the only way to make pressurized rovers and rescue pods that match the FusTek aesthetic.

[Joshwoo70]

I wish I could contribute...

[SebFierce]

What are the merits of a FusTek Fairing over Procedural ones?

[Korb Biakustra]

These would be shielded if I understand correctly. And overall, non-procedural fairings are a very good/interesting practice for optimizing size and compactness of payloads, and hence can sometimes discourage from making very large payloads with very large rockets as we would perhaps do easily with procedural fairings that will fit even the most bizarre designs.

I do use Procedural fairings quuite extensively, but I've had a lot of fun with fixed-size AIES fairings. Last time, my challenge was to launch solar panels for my space station into Kerbin orbit, in one launch, and with a regular-sized-realistic-ish rocket (see below in tiny size due to off-topic, sorry; I'll remove it if you prefer Sumghai).

I finally used procedural fairings for the final rocket so this is kind a of very bad example. However, I first made sure the 12 solar panels fitted in the AIES fairings, and then took the Procedural fairings only because I have "KW Rocketry black and white" HD texture for them, and I usually dedicate this texture to unmanned payloads.

Inside AIES fairings.

Closer look, inside Procedural fairings:

Deployment of the panels (that was just a trial, actual solar panels were sent to 600 Km orbit):

I would probably never have optimized the payload volume like that if I had only procedural fairings in the VAB. Procedural fairings are awesome; non-procedural fairings are cool too, especially if shielded.

Edited May 24, 2014 by Korb Biakustra

[SebFierce]

The procedural ones are shielded too, in regards to FAR. With DeadlyReentry some slight modifications would be needed in a ModuleManager patch, that's true.

Apart from that I think everybody should work by their own rules. And if I have a house-rule to not build overtly voluminous payloads a "hard" fairing doesn't offer anything over PF tbh.

Edit: Mighty fine robotics on that payload there (Couldn't look at the pics at work earlier)

Edited May 23, 2014 by SebFierce

[futrtrubl]

Seems to be a node issue between the Quest Legacy top node and the 1.25m IACBM.

[sumghai]

I wish I could contribute...

Add-on authoring, be it modelling new parts or writing a plugin to introduce new functionality, is a totally different animal to redistributing existing work in "mod packs".

There's an extensive compilation of how-to guides for various aspects of add-on authoring, which you may find useful.

What are the merits of a FusTek Fairing over Procedural ones?

These would be shielded if I understand correctly. And overall, non-procedural fairings are a very good/interesting practice for optimizing size and compactness of payloads, and hence can sometimes discourage from making very large payloads with very large rockets as we would perhaps do easily with procedural fairings that will fit even the most bizarre designs.

The procedural ones are shielded too, in regards to FAR. With DeadlyReentry some slight modifications would be needed in a ModuleManager patch, that's true.

Apart from that I think everybody should work by their own rules. And if I have a house-rule to not build overtly voluminous payloads a "hard" fairing doesn't offer anything over PF tbh.

One of my personal peeves with Procedural Fairings is that it allows some folks to build, in some extreme cases, a giant egg-shaped payload pushed by a tiny lifter rocket.

In real life, rockets generally benefit from standardized components (economies of scale from mass production, yada yada), and I just can't see myself resorting to bespoke solutions every time I launch a payload. Another point to consider is that, even if your lifter has the delta-v to push a given payload into orbit, it's bad engineering practice to have said payload be too long / too wide (structural stresses at launch and maneuvering, yada yada).

I think this is what I like about the KW Fairings - they force you to make sensible design choices about how to divide up your payloads into manageable sections to be assembled in orbit. Of course, having a large number of part variants just to support various diameters is a bit of a detriment.

I suppose my plan for the proposed SDHI Fairing System is to combine the best of both worlds (unfortunate implications notwithstanding) - the standardization of diameters / length increments in KW and the part count reduction / tweakability of Procedural Fairings. Aerobrakable fairings is just an added bonus.

Bear in mind, of course, I'm in no position to dictate other people's playing style. It's just that this idea has been on my mind for sometime, but it is only because of the recent trend of tweakable did said idea seem more feasible.

Of course, I've got lots of my plate right now, with MM configs and IVAs to make for FusTek, some ideas on further improving the SDHI Service Module, that FusTek SEV I've always wanted to make and now shielded fairings. I'd better go have a good cry before I get too excited:

Seems to be a node issue between the Quest Legacy top node and the 1.25m IACBM.http://edowner.net/quest-legacy-dock.jpg

Nope, that's by design.

Like the real-life ISS Quest airlock it was based on, the Kuest Legacy's top attachment node is not supposed to have a docking port there - in fact, you'll find that I've configured my CLS / Ship Manifest patch to render any docking ports attached to that location effectively useless.

The only reason airlocks have top attachment nodes is to allow them to be flown backwards to a station and docked, before the ferrying propulsion stage is discarded:

[CptRichardson]

If I may make a suggestion, there are two urgent Quality of Life/Build fixes/upgrades that need to be made/need an alternate D/L pack for their implementation on all parts.

1: Running Lights for all modules. I don't mean the internal lights, but external ones to include Red to Port, Green to Starboard directional locator lights located by any docking port for ease of docking alignment, and several standard white lights along strategic points of the modules to make them easier to see in the dark.

Why? For one, adding these myself to make docking and navigating around my station when eclipsed by the local primary body takes up an additional 4-20 parts per module. And given the rather... non-reflective state of the modules (read: unless you have a couple of spotlights, you won't see them until the CLANG), even the paltry lights on the pack's docking collars don't really help out in locating and docking with the station. Additionally, marking the docking ports/module ends with the proper running light scheme makes it really easy to figure out which way is which compared to the station and eases the navigational burden of trying to figure out which way to rotate your current docking module in order to be properly lined up.

Implementation strategies: I can see two ways for adding lights to the parts. The first is dedicated geometry with adding in little nodes to show where they are located. This would be the long-term method of adding these to the currently existing modules, seeing as they would take dedicated modeling time. The second would be to slightly alter the textures so that they appear to have little light fixtures installed or recessed into the surface, so as to save geometry and time, with the light source being directly emitted from the module itself instead of a geometry feature. I know that not everyone might want this, which is why I've suggested making an alternate part pack without this and the other suggestion I have.

2: A reletively harder, but no less necessary addition/change: Modules with at least one set of four RCS blocks directly installed onto them.

Why?

This is my other major part count killer on major stations. Lacking RCS when trying to build the station, or when attempting to alter it's orientation is just plain frustrating. Plus, having RCS helps keep the place stable when things inevitably go 'Clang'. You need at least one set, set equidistantly around a module in order to properly maneuver a block in orbit or use it as a control point when shifting. But that is still at least 4 parts wasted on keeping control, when you could reduce the part count on most stations by making them an intergal part of the superstructure.

This, unfortunately, will take more work. One way would be to install a set using mostly textures onto/into the Karmony End Ring system (both directly integrated into the part and the free-standing version. They're thick enough to pass things off as having buried the system inside of the end ring, and you get a fair number of control thrust directions from the design. Additionally, it gives further reasons to use them besides hooking into a hub on the station. Alternatively, as with the lights suggestion, you could model an alternative set with a set of four RCS blocks added in via modeling.

[phoenix_ca]

I like both of those ideas. Pretty please, sumghai. Lights and RCS integrated into your parts would make them utterly fantastic.

[sumghai]

1: Running Lights for all modules.

Not planned.

The USOS modules on the ISS don't have individual running lights.

2: A reletively harder, but no less necessary addition/change: Modules with at least one set of four RCS blocks directly installed onto them.

I experimented with embedding RCS thrusters into tapered modules several months back, and what many of us have found is that the stock RCS thruster behavior doesn't handle roll inputs properly if thrusters were built-in, due to the pod considering the thrusters turning about its centre of axis in a peculiar way. I've heard that there's a plugin-based PartModule that improves on the stock behavior and thus fixes the aforementioned issue, but at this point in time, it's very low on my ever-growing list of priorities right now.

[phoenix_ca]

Not planned.

The USOS modules on the ISS don't have individual running lights.

Well...that's a let-down. It might not be realistic, but it would be useful for keeping part-counts down.

Guess it's time for me to see what I can do with Photoshop.

[sumghai]

LINK REMOVED - patch is now part of main download itself

Place this in GameData\FusTek\Station Parts\Parts\MM_configs along with the other official MM patches. This will be a standalone download until I integrate it with the eventual full R0.04a release.

This adds varying combinations of crew provisions and/or waste storage tanks to certain station modules, compatible with TAC Life Support:

- All crew-occupiable and some crew-traversable modules have oxygen storage and air recyclers (Carbon extractors)

- The Habitation and Logistics modules is the main food storage

- Given that TAC requires Kerbals on EVA to take half a day's worth of provisions with them, airlocks also hold some provisions

- Otherwise, food is strictly off-limits in other modules such as the Science Lab and the Kupola

- I've decided that the FusTek Resupply Module will not use Modular Fuel Tanks for the crew provisions, to simplify life support logistics and handling. However, at some stage I will add MFT functionality for the monoprop/LOX resupply capability (currently not implemented)

Note that this particular patch is a WIP - there's a few other bits and pieces I need to mull over.

Edited June 8, 2014 by sumghai
LINK REMOVED - patch is now part of main download itself

[Korb Biakustra]

If I may make a suggestion, there are two urgent Quality of Life/Build fixes/upgrades that need to be made/need an alternate D/L pack for their implementation on all parts.

1: Running Lights for all modules. I don't mean the internal lights, but external ones to include Red to Port, Green to Starboard directional locator lights located by any docking port for ease of docking alignment, and several standard white lights along strategic points of the modules to make them easier to see in the dark.

Why? For one, adding these myself to make docking and navigating around my station when eclipsed by the local primary body takes up an additional 4-20 parts per module. And given the rather... non-reflective state of the modules (read: unless you have a couple of spotlights, you won't see them until the CLANG), even the paltry lights on the pack's docking collars don't really help out in locating and docking with the station. Additionally, marking the docking ports/module ends with the proper running light scheme makes it really easy to figure out which way is which compared to the station and eases the navigational burden of trying to figure out which way to rotate your current docking module in order to be properly lined up.

Implementation strategies: I can see two ways for adding lights to the parts. The first is dedicated geometry with adding in little nodes to show where they are located. This would be the long-term method of adding these to the currently existing modules, seeing as they would take dedicated modeling time. The second would be to slightly alter the textures so that they appear to have little light fixtures installed or recessed into the surface, so as to save geometry and time, with the light source being directly emitted from the module itself instead of a geometry feature. I know that not everyone might want this, which is why I've suggested making an alternate part pack without this and the other suggestion I have.

2: A reletively harder, but no less necessary addition/change: Modules with at least one set of four RCS blocks directly installed onto them.

Why?

This is my other major part count killer on major stations. Lacking RCS when trying to build the station, or when attempting to alter it's orientation is just plain frustrating. Plus, having RCS helps keep the place stable when things inevitably go 'Clang'. You need at least one set, set equidistantly around a module in order to properly maneuver a block in orbit or use it as a control point when shifting. But that is still at least 4 parts wasted on keeping control, when you could reduce the part count on most stations by making them an intergal part of the superstructure.

This, unfortunately, will take more work. One way would be to install a set using mostly textures onto/into the Karmony End Ring system (both directly integrated into the part and the free-standing version. They're thick enough to pass things off as having buried the system inside of the end ring, and you get a fair number of control thrust directions from the design. Additionally, it gives further reasons to use them besides hooking into a hub on the station. Alternatively, as with the lights suggestion, you could model an alternative set with a set of four RCS blocks added in via modeling.

I like request 1, just the standard lights part. The texture of FusTek modules is indeed not very reflective, and I always add some lights to the modules but it hurts my heart each time I do that because I keep telling myself "watch the part number!"

I don't like idea 2. RCS placement is a design task and I want to be able to place them where I want while scratching my head to reduce the total number. If I have a long block of two modules, I'd rather try to place just a set in the middle instead of one on each part, or one set on each part rather than two sets on each part's ends. Additionally, I don't think every module should be RCS-capable on its own. Finally, you would need a unmanned command module each time you want to control a FusTek module. I prefer keeping thrust, flight control and miscellaneous facilities well separated. If I build a symetric station with no RCS on the modules, and later want to add some, then it's time to rethink the design and either upgrade (replace) the modules were RCS would be optimal, or expand the station by adding small RCS engines and command modules in strategic locations.

To build stations without RCS thrusters on the modules, in order to keep the part count as low as possible, I've used a reusable RCS robot, with adjustable RCS position to match the center of mass of the object to move (see below), and I'd be frustrated if such strategies would become useless/counterintuitive if all FusTek parts were autonomous.

Edited May 24, 2014 by Korb Biakustra

[okan170]

Are there any plans for a spacer type of a part? Usually I use two of the docking adapters stuck together in the VAB to make sure the modules don't clip into each other, though this does add to part count. If not, no biggie there are always other options, I just rather like the aesthetic.

The day IVAs arrive, this is going to have to be a mandatory mod for my future installs!

[DPooly]

Hio. So, I am getting an in-game crash. Not a loading screen crash, but random in-game crashes(Within 1-3 minutes) and I have narrowed the culprit to this mod.

My Specs;

Asus G750-JW Notebook

Intel Core i7-4700HQ 2.4 GHz

12GB RAM

1TB HDD

NVIDIA GeForce GTX 765M GPU

I have B9_Aerospace, a couple other mods for one or two random parts, and a mod of my own which is just stock engines that I added power and efficiency to. ExsurgentEngineering, too. Not sure what that mod does. I forgot. hehe. I have the Firespitter that came with B9_Aerospace.... Ummm... K3? It has been so long since I have downloaded mods that I forget which are mods and which are KSP.

[Korb Biakustra]

Also, it would be nice if internal lights were switched on/off depending on "inhabited" status: if a Kerbal is in a module, the light is on, otherwise it's off. It would help figuring out where actually are the Kerbals when looking at a populated station.

[CptRichardson]

So, we can't directly add RCS onto the station parts?

Okay. Fair enough, the reasons are reasonable enough. So, how about an optional part (not a part of the core download) instead?

Karmony Modular Maneuvering System (Type 2)

Based off of the Karmony Bulkhead. 1/4 meter thick by the diameter of a standard module plus a quarter meter on both sides due to the RCS blocks. No Onboard SAS. No onboard Power, or Monopropellant. Can be passed through. Omnidirectional, but with minimal thrust. For obvious reasons, it can't be used with the Karmony Ring adaptor ends, and may have clearance issues with fairings designed to just barely squeeze in a standard module.

Lighting optional, set in the center line of each of the RCS blocks, optionally either international navigation standard or just standard white spotlights. As a way of balancing it, you could set it so that the nodes are set inside of it, so that the docking adaptors for the pack won't work with it properly and will instead bounce off if you try to attach a collar to this. Fluff text could include the facts that it was designed for super-massive stations and the unique design challenges inherent in their construction.

[sumghai]

I like request 1, just the standard lights part. The texture of FusTek modules is indeed not very reflective, and I always add some lights to the modules but it hurts my heart each time I do that because I keep telling myself "watch the part number!"

I'm still not keen on running lights for individual modules.

With regards to module reflectivity, I've been wanting to do an updated art pass for quite some time. nothke complained that I didn't have specular on my modules, but when I asked him what specific settings I should use for Unity, he never got back to me on this.

I don't like idea 2. RCS placement is a design task and I want to be able to place them where I want while scratching my head to reduce the total number. If I have a long block of two modules, I'd rather try to place just a set in the middle instead of one on each part, or one set on each part rather than two sets on each part's ends. Additionally, I don't think every module should be RCS-capable on its own. Finally, you would need a unmanned command module each time you want to control a FusTek module. I prefer keeping thrust, flight control and miscellaneous facilities well separated. If I build a symetric station with no RCS on the modules, and later want to add some, then it's time to rethink the design and either upgrade (replace) the modules were RCS would be optimal, or expand the station by adding small RCS engines and command modules in strategic locations.

To build stations without RCS thrusters on the modules, in order to keep the part count as low as possible, I've used a reusable RCS robot, with adjustable RCS position to match the center of mass of the object to move (see below), and I'd be frustrated if such strategies would become useless/counterintuitive if all FusTek parts were autonomous.

http://reho.st/http://i.imgur.com/lmJ1UpSl.jpg

http://reho.st/http://i.imgur.com/QeM49Vhl.jpg

http://reho.st/http://i.imgur.com/ZUlp5AMl.jpg

This.

I also prefer having mini-tugs / robot arms help assemble my stations. In fact, one of the uses of my proposed FusTek SEV project would be to use them for servicing space stations, just like the workbees used to service Starfleet ships from Star Trek.

Are there any plans for a spacer type of a part? Usually I use two of the docking adapters stuck together in the VAB to make sure the modules don't clip into each other, though this does add to part count. If not, no biggie there are always other options, I just rather like the aesthetic.

I've been seeing this request quite frequently lately. I'm not sure why people want to be positioning nodes side by side.

Also, it would be nice if internal lights were switched on/off depending on "inhabited" status: if a Kerbal is in a module, the light is on, otherwise it's off. It would help figuring out where actually are the Kerbals when looking at a populated station.

This sounds like it would require a plugin-powered enhancement. I really do like this idea, but I'm not sure how to implement this.

Another, planned use of such a feature would be an exterior status indicator light for the airlocks:

While on that matter... I don't know if this is possible without a plugin, but any way to alter that to indicate whether there's space in the airlock for a Kerbal's ingress? e.g.:

- Green light; come on in (Airlock empty)

- Red light; Jeb's just in the shower getting the Mun dust off. Please stand by, your EVA is important to us...

[Starwaster]

I'm still not keen on running lights for individual modules.

With regards to module reflectivity, I've been wanting to do an updated art pass for quite some time. nothke complained that I didn't have specular on my modules, but when I asked him what specific settings I should use for Unity, he never got back to me on this.

1. Edit the art files and give each one an alpha channel. You'll have to save it as something that supports alpha properly. If you're using photoshop, it doesn't support alpha properly for png files. There's a 'SuperPNG' plugin that does but I've never really got that to work properly so I use tga with compression. Save as 32 bit.
   
2. Edit the Unity3D files you have for each part and set the shader to KSP/Bumped Specular
   

As far as the alpha channel itself goes, black is no specularity at all and white is full specularity.

Edited May 25, 2014 by Starwaster
Realized those steps were in reverse order of what they should be.

[Korb Biakustra]

[...]

Thanks for the reply! Alright for the standard lights, that's your mod and I can understand why you don't want them, no worries!

I hope you'll find a way for the automatic internal lights, I'm glad you like the idea. By the way, I really like the Airlock status idea too, and in fact I had it in mind too in my previous post but did not want to ask too much at once.

So, we can't directly add RCS onto the station parts?

Okay. Fair enough, the reasons are reasonable enough. So, how about an optional part (not a part of the core download) instead?

http://i.imgur.com/DQKr9eg.jpg

Karmony Modular Maneuvering System (Type 2)

Based off of the Karmony Bulkhead. 1/4 meter thick by the diameter of a standard module plus a quarter meter on both sides due to the RCS blocks. No Onboard SAS. No onboard Power, or Monopropellant. Can be passed through. Omnidirectional, but with minimal thrust. For obvious reasons, it can't be used with the Karmony Ring adaptor ends, and may have clearance issues with fairings designed to just barely squeeze in a standard module.

Lighting optional, set in the center line of each of the RCS blocks, optionally either international navigation standard or just standard white spotlights. As a way of balancing it, you could set it so that the nodes are set inside of it, so that the docking adaptors for the pack won't work with it properly and will instead bounce off if you try to attach a collar to this. Fluff text could include the facts that it was designed for super-massive stations and the unique design challenges inherent in their construction.

That seems to me like a good and reasonable workaround, the best of both worlds, and still choice to the user.

[OOZ662]

To build stations without RCS thrusters on the modules, in order to keep the part count as low as possible, I've used a reusable RCS robot, with adjustable RCS position to match the center of mass of the object to move (see below), and I'd be frustrated if such strategies would become useless/counterintuitive if all FusTek parts were autonomous.

I use a spacetug myself, with 8 RCS blocks and 4 of the stock little orange radial engines pointing out the "back" toward the 2.5m docking port, with a 1.25m port on the nose. I've discovered, however, that the physics of the radial engines fail when docked to a part (at least on the 2.5m end; the 1.25m one doesn't see much use in hauling); they'll burn their fuel, make their noise and visually thrust all day and give absolutely zero deltaV but a squirt out of the RCS system works as expected. I have such a massive pile of mods that diagnosing the cause of this would probably be hell, but I'm curious if anyone else has experienced it.

[Korb Biakustra]

I have no idea sorry, mine only carries monopropellant and three small AIES RCS thrusters (can take a while to move around a big module :<).

Would you have a picture of your tug? In PM maybe if Sumghai doesn't want us to continue off-topic.