FusTek Station Parts Dev Thread (continuation of fusty's original work)

[TK421d]

sweet, this is one of my favorites, glad its still getting love

[BLUAV8R]

What would be awesome is if someone was to make a retexture that matches the KSO Phase II Station Parts I'm trying it now by matching the default color but may also do more such as add "foil" kind of look in lighter areas as well dependent on my skills lol

[BLUAV8R]

Is proud to present:

KSO Phase II FusTek Retexture

Javascript is disabled. View full album

DOWNLOAD (Dropbox)

What is it?

- This is a custom retexture for sumghai's latest dev release of his FusTek Station Parts Expansion. It is meant to make the textures seem a little more realistic as well as matching with those of Helldiver & Nazari1382's Kerbin Shuttle Orbiter System Pack.

What if I don't use the KSO pack?

- This is still (in my opinion) a very good standalone texture pack and is quite stock friendly.

What if I don't like the brown rims on the modules?

- Well then lucky for you I also have included in the download an optional pack that has those removed and is all grey If you decide to use this then make sure you use the default normal map included in the original version, not the one I have made. Check the end of the Imgur album to see the grey pack textures.

INSTALLATION INSTRUCTIONS

For standard pack simply copy over files in GameData folder to those in your KSP location, overwriting all it says to.

If choosing to use the optional grey pack DO NOT USE THE NORMAL MAP (purple picture thing) INCLUDED IN MY PACK, USE DEFAULT ONE FROM ORIGINAL DOWNLOAD

Special thanks to sumghai for letting me post this & help with normal maps, and to blackheart612 as well for additional info on editing normals along with creative input

Shoot me a PM if you have any questions, constructive (or negative I guess lol) criticism, suggestions, or tips!

[sumghai]

Progress Report, 15 April 2014

As soon as Sippyfrog released his alternative texture pack, I knew I had to try this:

Fig 49 - (WIP) FusTek Station Parts - Texture Switching

After poking around with ModuleManager configs a bit, I managed to get most of Sippy's alternative textures loaded and made available in-game via Firespitter's FStextureSwitch. This would allow folks to mix and match FusTek modules of different styles and add interest to their stations, without having to manually duplicate parts in their GameData folder.

Bear in mind that this is still very much a work in progress - as you may have noted, the current version of FStextureSwitch has trouble handling multiple objects with identical names, which becomes relevant especially as X0.04a employs asset re-use via MODE{} node calls to a handful of "common" geometries. For instance, FusTek modules with two tapered ends would end up having one taper being updated via FStextureSwitch, while the second one would be ignored.

I've posted a comment in Snjo's thread, with the hope that he could address this in a future update of Firespitter. For now, I'll just go back to doing IVAs (and not being distracted by the next shin- ooh, blinking light!)

[sumghai]

X0.04-3 DEV BUILD released - refer to the blog post for download link

Just to keep y'all on your toes with some tweaks and extra functionality, while I work on the internals.

X0.04-3 DEV BUILD

WARNING: Minor save / craft-breaking update - use at own risk

Dependencies

- Firespitter plugin, for part animations and texture switching

- Connected Living Spaces (CLS) API, for determining which compartments are habitable/traversable

- ModuleManager, for applying patches for functionality/features provided by dependencies and third-party add-ons

- Ship Manifest / Kerbal Crew Manifest plugin, for transferring crew between non-airlock compartments without EVA

X0.04-3 DEV BUILD  24 April 2014
---------------------------

Features:
 - Modules now (tenatively) 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

[TK421d]

sweet, i was just about to start building a new station anyway

also, have you considered fuel tanks? i always make my stations double as fuel-depots, and it always seems just to keep the visual aesthetic i add one or two of the warehouses full of batteries and monoprop.

[Moon Goddess]

I think he's said before that there are other great fuel tanks and they're arn't any fuel depots on the ISS, so it doesn't fit the theme.

[TK421d]

i wish large builds were more than just a novelty... only get about 4-6 fps with this bad boy

[Bioman222]

i wish large builds were more than just a novelty... only get about 4-6 fps with this bad boy

http://i.imgur.com/tCceKz2.png

Dun dun dun dun dun... Dun dun... dun dun...

[sumghai]

also, have you considered fuel tanks? i always make my stations double as fuel-depots, and it always seems just to keep the visual aesthetic i add one or two of the warehouses full of batteries and monoprop.

I think he's said before that there are other great fuel tanks and they're arn't any fuel depots on the ISS, so it doesn't fit the theme.

As I explained in the release thread's FAQ, fuel tanks won't really fit the theme of FusTek - besides, there's the slippery slope argument that may lead someone to further suggest engines, also outside the scope of FusTek.

My 0.20.2 FusTek space station had a lower section with several Rockomax Jumbo fuel tanks docked to it - the two different styles offer a nice visual segregation of "habitation" and "industrial" areas.

[sumghai]

Progress Report, 2 May 2014

Had a rather busy couple of weeks, but work on IVAs continues:

Fig 50 - (WIP) FusTek Kirs Docking Module - Internals (2)

One of the things I really liked about KSP from 0.20 onwards was the introduction of MODEL{} nodes, allowing for asset reuse in parts. As far as I'm currently aware, there is no equivalent for IVAs, so I decided that certain common structural features, such as the end hatches, corridor frames etc will be defined as props rather than as part of the base internal models.

Right now, I'll go ahead and confess that I'm still new to the IVA authoring scene, and that I haven't got my workflow sorted out properly - apparently, I hadn't installed PartTools properly in Unity from the very beginning of this project, resulting in a non-functional Prop Tools / Prop Library system. Subsequently, the hatches you guys are seeing in the the Kirs IVA WIP were actually manually placed through hours and hours of derping around with quaternion rotations, not something I want to repeat for subsequent props like RPM buttons and screens.

So until I figure out how to install PartTools properly (and not have weird uncloseable blank PartTool windows cluttering up my screen), work on IVAs is going to be much slower than expected.

---

In other (not so good) news, nothke has abandoned FLEXracks.

Since the Warehouse module was built around a potential FLEXracks implementation, and that Universal Storage doesn't quite fit the visual theme and functionality in FusTek, I would like to formally announce that I intend to take over the FLEXracks project, albeit in a truncated capacity and as a separate download to FusTek. More details will come when I start a thread dedicated to FusTek FLEXracks.

Edited May 2, 2014 by sumghai

[Helix935]

I would like to formally announce that I intend to take over the FLEXracks project, albeit in a truncated capacity and as a separate download to FusTek. More details will come when I start a thread dedicated to FusTek FLEXracks.

YESYESYESYESYESYESYESYES!!!!! glad to see that it will be saved by someone as skilled as you Sumghai

[BananaDealer]

Since the Warehouse module was built around a potential FLEXracks implementation, and that Universal Storage doesn't quite fit the visual theme and functionality in FusTek, I would like to formally announce that I intend to take over the FLEXracks project, albeit in a truncated capacity and as a separate download to FusTek. More details will come when I start a thread dedicated to FusTek FLEXracks.

Praise the Sun!

[sharpspoonful]

Praise Kerbol!

FTFY, BananaDealer.

[montyben101]

For some reason the parts arnt showing up in the vab/sph what am i doing wrong?

[sumghai]

For some reason the parts arnt showing up in the vab/sph what am i doing wrong?

- Are you using the stable R0.03.5a release, or the experimental X0.04-3 dev version?

- Are you in career or sandbox mode?

- If you are in career mode, have you unlocked the composites node? (by playing the game, gathering science points and spending them in the R&D centre)

[SebFierce]

So Sumghai I don't know what exactly you intend to do with Flexrack but there is an alternative Rack system now which may save you some time (in case that particular idea already fits what you want to develop from Flexrack):

http://forum.kerbalspaceprogram.com/threads/76018-VTS-The-Versatile-Toolbox-System

[sumghai]

So Sumghai I don't know what exactly you intend to do with Flexrack but there is an alternative Rack system now which may save you some time (in case that particular idea already fits what you want to develop from Flexrack):

http://forum.kerbalspaceprogram.com/threads/76018-VTS-The-Versatile-Toolbox-System

It has some ideas that I want, but not the form factor I am looking for. Also, while I do have the one official model nothke emailed me, my hands are tied until he officially clears his work for release.

In other news, I finally figured out the problem with my IVA creation workflow (an add-on with a dodgy CFG file), such that PropTools now works smoothly. I'll post some updates later this week.

[falken]

For some reason if I try entering an airlock hatch on either the regular or legacy modules, the kraken attacks, be it me on the ground or in orbit.

e: Rolled back to R0 03 5a1 and it's all working fine again.

Edited May 17, 2014 by falken

[sumghai]

For some reason if I try entering an airlock hatch on either the regular or legacy modules, the kraken attacks, be it me on the ground or in orbit.

e: Rolled back to R0 03 5a1 and it's all working fine again.

Please post support questions in the main announcements thread.

Also, reports of "Kraken" attacks are too vague for me to attempt resolving the issue.

[Starwaster]

Please post support questions in the main announcements thread.

Also, reports of "Kraken" attacks are too vague for me to attempt resolving the issue.

But I have a picture of The Kraken destroying my station

Edited May 18, 2014 by Starwaster

[sumghai]

But I have a picture of The Kraken destroying my station

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

What you're seeing there is actually the Loch Ness Monster a prototype snorkel apparatus for Kerbal commandos, developed by the Winters-Mading Institute of Theoretical Sciences, taken about a week before the mysterious fire that burned their entire campus (staff included) to the ground.

[Starwaster]

What you're seeing there is actually the Loch Ness Monster a prototype snorkel apparatus for Kerbal commandos, developed by the Winters-Mading Institute of Theoretical Sciences, taken about a week before the mysterious fire that burned their entire campus (staff included) to the ground.

I think I met one of them! He kept nagging me to let him borrow 'tree-fiddy'...

[sumghai]

Progress Report, 19 May 2014

Despite having resolved the PartTools/PropTools issue, I hit another snag with IVAs - specifically, the hatches inside the modules.

As most of you are aware, I like to impart a certain amount of realism to my designs. The design requirements for the FusTek hatches are thus:

- Inward opening (For safety reasons, the hatches should utilize the internal pressure of the modules to keep themselves sealed when not in use. Inward opening hatches also ensure compatibility with adjacent FusTek modules)

- Permit at least one Kerbal in shirt-sleeve attire to pass through easily

- Lightweight

- Compact mechanism that can work for both flat and taper-ended module variants (As to not occupy too much internal volume otherwise reserved for crew habitation)

Given these requirements, the logical solution appeared to involve pulling the hatch inwards slightly and then sliding it upwards on rails into the bulkhead. Since we can see from the actual in-game parts that the hatches stick out of the bulkheads by 31.25 mm, additional thickness is required for them to seat properly within the cutouts in the bulkheads.

My first attempt, depicted in Figure 51, assumes a hatch thickness of 62.5 mm (2x 31.25mm), and involves a 100 + 100 mm stepped hatch frame.

Fig 51 - FusTek Karmony Hatch Study (1)

At first glance, this seemed to meet all of the requirements, but upon closer inspection it can be observed that the hatch will rest against a very thin (18.75 mm) piece of hull, which will most definitely buckle from the internal pressure pushing against the hatch. The position of the patch relative to this thin panel also means very little thickness is available for the stepped rim that prevents the hatch simply popping out.

My next attempt proved to be much more promising:

Fig 52 - FusTek Karmony Hatch Study (2)

Here I resolved to make the inner bulkhead thickness uniform at 156.25 mm (the same thickness as the standard Karmony Bulkhead piece), and opted for a 50% thicker hatch (93.75 mm). This results in the hatch rim pushing against a thicker and more structurally-sound piece of hull (31.25 mm), without compromising the size of the opening.

In terms of how I would actually implement this in KSP, I've already made common internal geometries, such as hatches and support frames, into props, making it a simple matter of editing said prop and letting the changes automatically propagate to all Karmony modules - the hatches will actually be depicted as permanently closed while in IVA (since we obviously can't see through to the inside of other modules*), and the rails/cutouts for when the hatch is opened will actually be made using normal maps.

*I am aware of the sfr plugin that allows IVAs to be visible from outside, but that needlessly complicates things in this particular context\

Just when I thought things were going swimmingly again, I got myself into another pickle:

Fig 53 - FusTek Kirs Hatch Study

The Kirs Docking module only has a diameter of 1.25m, compared to the 2.5m used by standard-sized Karmony series modules, which obviously leaves no room for the pull-in-and-slide-up mechanism I designed earlier. But to ensure efficient crew transfer between the station and visiting spacecraft via the Kirs tunnel, it is desired that the Kirs still use the same hatch size and design are those found in the Karmony series modules. The hatches still also need to open inwards, as to not collide / obstruct hatches in other compartments or visiting spacecraft.

While the hatches must be the same, since the Kirs itself is an unusual module, a bespoke hatch closing mechanism is acceptable. The question, however, is:

How do we design the hatch mechanism to work in such limited space?

(Considering that we need room for one Kerbal to monitor docking operations from inside the Kirs module, as well as stuff like pressure equalisation valves, JSI MFDs, electronics boxes, life support, fuel transfer hose stowage etc)

I'm now opening the floor to suggestions and ideas.

[Gryphorim]

Kirs: Garage-door style arrangement. Door pulls into hatch do disengage seal, then when clear of bulkhead, slides on rail to the side, rotating to parallel with wall.