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

[sumghai]

PNG/MBM textures and Blender source files now available - see announcements thread for download link

There's a fairly extensive thread discussing increased RAM usage in 0.20 and 0.20.2 - as expected, more people have problem using PNG textures than anything else even in 0.20.2, hence the reason the main download contains TGAs by default.

That said, after some (decidedly vocal and persistent) complaints, I've included PNG and MBM versions for folks to compare. I'm going to go on record by saying that I did not enjoy republishing textures in those formats. At all.

I've also put up source Blender files for people who want to have a look at how I've reverse-engineered fusty's modules. Note that most of the parts have a vertical offset of 0.675m downwards - it was the only way to keep the top hatch EVA-able while avoiding the exploding hatch bug (Don't ask me to move the hatch somewhere else; escape hatches on space station modules look quite silly).

[Railgunner2160]

I'd personally love to see the warehouse module for Orbital Construction Redux.....

[King Jareth]

Thanks for including model files thats really useful stuff.

[sumghai]

R0.02.2a DEV BUILD released - see announcements thread for download link

R0.02.2a DEV BUILD    28 June 2013
---------------------------

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 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 

Although I have yet to start on the new parts I wanted to add for R0.03a, I'm releasing this WIP release to quickly address the VAB/SPH slowdown issue - I recently setup a KSP 0.20.2 build and found that the lagging was most noticeable in the SPH.

[Read have Read]

Nicely done, no lagging or slowdown even when dragging a dozen modules around the VAB.

One other possible inspiration for a docking module, the Shuttle-Mir module

http://en.wikipedia.org/wiki/File:Docking_Module_%28STS-74%29.jpg

http://en.wikipedia.org/wiki/Mir_Docking_Module

Edit: Er...update may break attachment nodes.And the lights look funny in the dark on the Hab Module

Edit: Edit:

Surface attach on the MkIII node slides under the surface. Does not seem to affect the other models, and attaching docking ports/CBMs to the recessed nodes still work, but you could also surface attach to the recesses as well. Surface attachment takes the smaller collider cylinder size of the recesses.

I seem to be the bearer of bad news recently.

Edited June 28, 2013 by Read have Read

[internerd]

Woah. Sweet. Looks like a good excuse to build my first station.

[sumghai]

Nicely done, no lagging or slowdown even when dragging a dozen modules around the VAB.

One other possible inspiration for a docking module, the Shuttle-Mir module

http://en.wikipedia.org/wiki/File:Docking_Module_%28STS-74%29.jpg

http://en.wikipedia.org/wiki/Mir_Docking_Module

As a matter of fact, I'm very strongly leaning towards a FusTek'd Mir Docking Module, since I realise that some spacecraft we would build may have difficult-to-access docking ports (e.g. spaceplanes with docking ports enclosed inside cargo bays like the Space Shuttle).

Edit: Er...update may break attachment nodes. And the lights look funny in the dark on the Hab Module

From 0.02.1a onwards, the part origins and attachment nodes have been shifted in order to fix the "kerbals popping out between modules" problem. Vessels built prior to 0.02.1a will have this problem, while vessels built after 0.02.1a (including the 0.02.2a performance fix) will properly make use of the new shifted origins/attachment nodes.

As for the Hab lights, it might be due to textures being referenced incorrectly on your system - looks normal on mine.

I presume you have completely uninstalled (deleted) the old FusTek parts and replaced them with the new one? The new models only work with the new CFGs.

Edit: Edit:

Surface attach on the MkIII node slides under the surface. Does not seem to affect the other models, and attaching docking ports/CBMs to the recessed nodes still work, but you could also surface attach to the recesses as well. Surface attachment takes the smaller collider cylinder size of the recesses.

Now this one is a valid concern - I was able to reproduce it as well.

The Mk III Nodes from R0.02.1a BUGFIX had borked colliders, which although properly controls surface attachment, results in heavy lag.

In R0.02.2a DEV BUILD, I simplified the collider into a single narrow(er) cylinder in order to accomodate the surface attachment (KSP / Unity generally doesn't like concave parts). This is what's causing surface-attached parts slide underneath.

I'm working on a solution as we speak - something involving a cuboid in the center flanked by circular segments. As long as I keep them convex and not zero-thickness, I should be able to have proper surface attachment with non-lagging performance.

[sumghai]

Minor hotfix to R0.02.2a DEV BUILD released - see announcements thread for download link

This improves the Mk III Node colliders to prevent surface attached parts from sinking below the part surface, whilst still retaining the performance improvements from R0.02.2a. As this is a very minor fix that technically should have been implemented, there is no change to the patch notes - just re-download and re-install.

[sumghai]

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.

[Blaylock1988]

This is awesome, I would love to use your parts in conjunction with KASPAR and Orbital Construction! Maybe you can even incorporate Interplanetary Launchpads somehow

[MOARdV]

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.

Any possibility of a cargo bay type part without the payload racks? There have been a few times when I've wanted cargo bay that fits standard 2m hulls (as opposed to the B9 spaceplane parts). I know there's a Wayland part like that, but the cargo door covers like 120 degrees of the surface, so it is hard to use for anything much bigger than 1m.

[sumghai]

Any possibility of a cargo bay type part without the payload racks? There have been a few times when I've wanted cargo bay that fits standard 2m hulls (as opposed to the B9 spaceplane parts). I know there's a Wayland part like that, but the cargo door covers like 120 degrees of the surface, so it is hard to use for anything much bigger than 1m.

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.

[Devo]

Any possibility of a cargo bay type part without the payload racks? There have been a few times when I've wanted cargo bay that fits standard 2m hulls (as opposed to the B9 spaceplane parts). I know there's a Wayland part like that, but the cargo door covers like 120 degrees of the surface, so it is hard to use for anything much bigger than 1m.

How big do you want it to be? send me a PM. I'm not so anal about requests.

[sumghai]

I'm not so anal about requests.

Harsh, man. Very harsh.

[sumghai]

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).

[Talisar]

That looks great, just what I was looking for. Thanks!

[MOARdV]

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.

The models and animations fit my needs. I hadn't seen them previously. The texture ... well, I suppose if I wanted the carbon fiber look, they'd be perfect. I guess I can hack on the textures and figure out if there's a real UV map on them that makes the part salvageable, as it were.

[sumghai]

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.

[Mekan1k]

Why 'sheer unbridled horror'?

[sumghai]

Why 'sheer unbridled horror'?

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.

[Creideiki]

I love the look of the Kirs module. Though I must ask, will you ever implement a stepped design of airlock/docking adapter/thing as your original Kuest mockup? I ask, as it's a lovely design.

Also, may I inquire as to why the CoM of the Karmony Node isn't centred? Is it due to the whole avoiding explosion on Kerbal EVA fix? I ask as it took me forever to get my station core balanced in terms of RCS. On the other hand the entire exercise did provide me a good place to mount the quantum strut core. So my monolithic station core didn't go all wibbly wobbly atop it's giant launcher rocket.

[Moon Goddess]

oooo I see Kirs as being a major peice of my future space sation designs, much better than the stock structural fuselage.

[Mihara]

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.

It sounds like "Kurs". Which is Russian for 'heading'.

[Archer]

I love the look of the Kirs module. Though I must ask, will you ever implement a stepped design of airlock/docking adapter/thing as your original Kuest mockup? I ask, as it's a lovely design.

<clip>.

I too would enjoy the stepped design, though this looks excellent (as usuall).

[sumghai]

I love the look of the Kirs module. Though I must ask, will you ever implement a stepped design of airlock/docking adapter/thing as your original Kuest mockup? I ask, as it's a lovely design.

I too would enjoy the stepped design, though this looks excellent (as usuall).

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.

Also, may I inquire as to why the CoM of the Karmony Node isn't centred? Is it due to the whole avoiding explosion on Kerbal EVA fix? I ask as it took me forever to get my station core balanced in terms of RCS.

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.

It sounds like "Kurs". Which is Russian for 'heading'.

Ah, cheers for that