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

[NoMrBond]

If you haven't had a KSP runnable laptop for 92 days how are you doing the modelling?

Also, what do you need to either fix the laptop you had before, or replace it if it's beyond fixing?

[TK421d]

3d modeling is MUCH less intensive than gaming, and believe it or not, relies very little on GPUs. there is an entire different branch of video card tech for 3d and architectual work

[sumghai]

If you haven't had a KSP runnable laptop for 92 days how are you doing the modelling?

3d modeling is MUCH less intensive than gaming, and believe it or not, relies very little on GPUs. there is an entire different branch of video card tech for 3d and architectual work

My current laptop is a second-hand circa-2005 business laptop, running Win 7 Pro with only 3GB of RAM. The previous owner was apparently a Microsoft DB administrator, so every now and then I'm uninstalling bits and pieces he left behind.

It can run SolidWorks 2008 and Blender very comfortably, and Unity editor reasonably well (albeit with a non-trivial startup lag), but stock KSP 0.90 and 1.0 becomes a practically unusable slide show with several minutes between scene changes or to respond to any user input.

Also, what do you need to either fix the laptop you had before, or replace it if it's beyond fixing?

In short, I need to buy a new laptop altogether.

Back when I was a postgrad, I used to have access to a desktop PC with oodles of RAM, decent processor and graphics card - I did my CFD research during the week, and add-on authoring on weekends.

Now that I've moved to Christchurch to start a full-time job, I'm stuck in an apartment with the aforementioned shoddy laptop. I thought about upgrading the RAM, but I found out that the machine could only support a maximum of 4GB - given that Win 7 eats up a fair bit of RAM, an extra gig wouldn't make much difference.

I can very easily afford a new laptop right away on my salary, but I don't like the current offerings that come with Windows 8 (personal experience, recommendation of family, friends and colleagues from academia/engineering). I know I can buy a downgraded Win 7 / Win 8.1 machine now and upgrade it to Win 10 later, but since Win 10 will require new drivers/BIOS/etc. to take advantage of its underlying features, I decided that it was best to wait until the Win 10 RTM in June/July and invest in a better machine then.

[TK421d]

heh, yeah i was never really sold on 8/8.1 either, im still happily running win7. 8 may be nice for tablets and thumbs, but its just not a good utility for pc or laptop use (despite their marketing otherwise).

at least you can still work on pretty new models and textures even if you cant play right now though maybe by the time you can play all these 1.0 bugs will be sorted out too!

[sumghai]

(Another quickie) Progress Report, 2 May 2015

Number of days without a KSP-runnable laptop: 94

MOARdV has finally helped me figure out why the Karmony module viewport switches weren't working.

Many of the viewports were given the "double-click-to-focus" hitboxes, and as it turned out, they were overlapping with the "toggle shutter" hitboxes. I've made the former into smaller cylindrical mesh colliders, so that they are well out of the way of the shutter toggles.

Ultimately, the viewport props will be modified to have actual buttons - an animated one for the window shutters, and a dummy one for demisting the window. But anyways, you guys should finally be able to close those viewport shutters at will.

The Kupola windows will use a slightly different system where a separate button prop will control the external part animation that toggles the blast shutters - we're leave that for another time, however.

[Beowolf]

I avoided 8.0, but bought a gaming laptop after 8.1 came out and am delighted with it. It's impressively fast in several ways, like power-on to login in 8 seconds. Then it's starting up the network interface in background while I'm typing my password, so I can immediately start working as soon as my desktop appears.

I also use a custom app launcher, so I never have to see that silly new UI of theirs at all.

But I agree with you about waiting and getting the latest, since it's so soon.

Hope you're enjoying the new job.

[Kanddak]

Hi Sumghai & FusTek fans,

Here's a plugin I wrote this weekend as an exercise in learning to write plugins: https://www.dropbox.com/s/3mwchh46pfpzeyb/ToggleModel.zip?dl=0

It toggles entire MODEL nodes on and off, rather than individual mesh objects like FSmeshSwitch. It can optionally toggle an attachment node as well.

The accompanying modulemanager file does the following:

• Allows the top & bottom end rings to be toggled independently on each of the tapered Karmony module variants.
  
• Hides all of the flat-ended module variants.
  
• On the Karmony node and its compact variant, adds the KarmonyNodeCover model over each of the side recesses, and allows each node cover to be toggled independently along with the associated attachment node.
  
• Allows the bottom end ring to be toggled on the two airlocks and the Kupola... revealing that these three models don't actually have bottom surfaces.
  

Known to work with station parts downloaded 2015-04-15 in KSP 0.90. My hope is that after some testing, this can be distributed with the station parts and the tapered & flat-ended variants can be consolidated. License: CC BY-SA 4.0 (selected to deliberately match FusTek).

[sumghai]

Here's a plugin I wrote this weekend as an exercise in learning to write plugins: https://www.dropbox.com/s/3mwchh46pfpzeyb/ToggleModel.zip?dl=0

It toggles entire MODEL nodes on and off, rather than individual mesh objects like FSmeshSwitch. It can optionally toggle an attachment node as well.

The accompanying modulemanager file does the following:

• Allows the top & bottom end rings to be toggled independently on each of the tapered Karmony module variants.
  
• Hides all of the flat-ended module variants.
  
• On the Karmony node and its compact variant, adds the KarmonyNodeCover model over each of the side recesses, and allows each node cover to be toggled independently along with the associated attachment node.
  
• Allows the bottom end ring to be toggled on the two airlocks and the Kupola... revealing that these three models don't actually have bottom surfaces.
  

Known to work with station parts downloaded 2015-04-15 in KSP 0.90. My hope is that after some testing, this can be distributed with the station parts and the tapered & flat-ended variants can be consolidated. License: CC BY-SA 4.0 (selected to deliberately match FusTek).

Ooh, sounds pretty cool! A couple of questions and thoughts:

- Does it modify mass/cost/etc dynamically as well? The top and bottom end rings have mass/cost associated with them

- I'm not sure about having the ability to dynamically patch over the side recesses on the nodes; the KarmonyNodeCover models were considered a concession part made available to users, and not really something I'd recommend for regular use

- The airlocks and the Kupola were always meant to be independen0tly-docked modules, rather than stacked inline

[Kanddak]

Does it modify mass/cost/etc dynamically as well? The top and bottom end rings have mass/cost associated with them

Not presently, but I can add that.

I'm not sure about having the ability to dynamically patch over the side recesses on the nodes; the KarmonyNodeCover models were considered a concession part made available to users, and not really something I'd recommend for regular use

Since we're already able to patch over the node recesses anyway, we may as well be able to do it without adding to the part count.

The main use case I've come across is in the use of a Karmony node parallel to the ground as a junction in a surface base; the recesses on the floor and roof should be covered. We don't want a hatch in a trapdoor orientation in our hallways -- if the Karmony node had an IVA we'd want to remove the interior hatch, too.

I've also stacked two compact nodes together and then blocked all four recesses on one of them in order to create a node with an off-center layout more similar to the real Harmony and Tranquility nodes.

The airlocks and the Kupola were always meant to be independently-docked modules, rather than stacked inline

I usually use them that way, but I often prefer to use flat variants with the 2.5m IACBM for greater structural stability, especially when modules are going to be under thrust together (for stations beyond LKO, manned segments of interplanetary vessels, etc), and because my tugs are usually standardized on 2.5m docking ports for other reasons.

But the Kupola does look pretty nice stacked on top of the compact Karmony node. That might make a good hub for a surface base.

[sumghai]

Does it modify mass/cost/etc dynamically as well? The top and bottom end rings have mass/cost associated with them

Not presently, but I can add that.

I'm not sure about having the ability to dynamically patch over the side recesses on the nodes; the KarmonyNodeCover models were considered a concession part made available to users, and not really something I'd recommend for regular use

Since we're already able to patch over the node recesses anyway, we may as well be able to do it without adding to the part count.

The main use case I've come across is in the use of a Karmony node parallel to the ground as a junction in a surface base; the recesses on the floor and roof should be covered. We don't want a hatch in a trapdoor orientation in our hallways -- if the Karmony node had an IVA we'd want to remove the interior hatch, too.

I've also stacked two compact nodes together and then blocked all four recesses on one of them in order to create a node with an off-center layout more similar to the real Harmony and Tranquility nodes.

I presume this means the four recesses are individually toggleable, correct?

I thought about surface bases for quite a bit as something for FusTek post-V1.0. I'd imagine that trapdoors in the corridors would be okay as long as one imagines there are ladders installed - this is one of two reasons why nodes and corridors don't have IVAs (the other reason being that they're not meant for long-term occupation in the same manner as Hab, Util and Sci Modules)

The airlocks and the Kupola were always meant to be independently-docked modules, rather than stacked inline

I usually use them that way, but I often prefer to use flat variants with the 2.5m IACBM for greater structural stability, especially when modules are going to be under thrust together (for stations beyond LKO, manned segments of interplanetary vessels, etc), and because my tugs are usually standardized on 2.5m docking ports for other reasons.

But the Kupola does look pretty nice stacked on top of the compact Karmony node. That might make a good hub for a surface base.

Again, I feel that the 2.5m docking flat-ended form factor was a concession I made reluctantly. I dislike the notion of people using the 2.5m form factor for hubs if the main reason they do so is for structural stability.

I generally design my stations to have closed loops (parallel docking with MechJeb FTW), or use various incarnations of the Docking Strut plugin to reinforced docked connections.

[Kanddak]

Just updated to affect cost and mass! Same download link above. I didn't bother to deduct the cost of the end rings from the base cost of the modules, though.

I presume this means the four recesses are individually toggleable, correct?

Correct. The two end rings are toggled independently from each other as well; the Karmony nodes each get six instances of the PartModule, with each one independently controlling a different MODEL node.

[sumghai]

Just updated to affect cost and mass! Same download link above. I didn't bother to deduct the cost of the end rings from the base cost of the modules, though.

If I decide to make use of your plugin, I will probably implement those cost differences.

The two end rings are toggled independently from each other as well; the Karmony nodes each get six instances of the PartModule, with each one independently controlling a different MODEL node.

I'm thinking of allowing the node covers to be toggleable independently, while the end rings will be toggled together (i.e. you get to choose between flat or tapered-end modules.

That being said, I should probably point out that I'm not exactly chomping at the bit to include this plugin just yet - while I do appreciate your work and the features it offers, I'm a bit concerned about certain users who continually complain about my use of dependencies, especially as I tend to prefer to ask people to install plugins themselves than bundle potentially outdated versions with my parts pack.

[Archer]

Bug report:

Installation:

KSP 1.0.2.842

Fustek Station Parts DEV (Downloaded: 6MAY2015)

Dependencies:

CLS 1.1.3.0 DEV (found at https://github.com/PapaJoesSoup/ConnectedLivingSpace/releases/tag/1.1.3.0)

MM 2.6.3

Ship Manifest 4.2.0.2

RasterPropMonitor 0.19.2

Issue:

All four Karmony modules appear to have their side node orientations reversed, top and bottom nodes are unaffected.

- Parts affected:

Karmony compactNode

Karmony compactNode Adapter

Karmony Node

Karmony Node Adapter

- Parts Tested

Karmony Node Cover

Karmony Node Cover - Viewport Variant

IACBM 1.25m

Clamp-O-Tron Docking Port

IACBM 2.5m*

-Testing

Attachment of the above parts was attempted on all six nodes of each Karmony module.

-The Top and Bottom nodes accepted attachment of each part as expected.

-None of the parts attached to the side nodes as expected.

--The Clamp-O-Tron and 1.25m IACBM clipped into the module and attached to their "back" node.

--The Node covers would not attach while oriented properly.

--When attempting to attach the Node covers inside-out, they clip into the module and attach.

-*The 2.5m IACBM was only tested on the Top and Bottom nodes of the flat variants, to satisfactory results.

-The issue does not appear while "Non-strict part attachment orientation checks" in the KSP debugging menu is checked.

[sumghai]

All four Karmony modules appear to have their side node orientations reversed, top and bottom nodes are unaffected.

Good catch!

I've pushed a commit - please let me know if it works properly now

[Archer]

Just retested all six attachment nodes on the four karmony nodes, they're working as expected.

[zyp]

Hi, I'm playing with this mod in my 1.0 career playthrough, and will submit feedback as I find stuff to report.

Is there a reason all parts have TechRequired = composites, rather than being grouped along with stock parts of similar functionality? I like the idea of building my station incrementally as I progress through the tech tree. Having all station modules under a single tech node kinda removes the point of playing career.

The science module isn't updated for the 1.0 science lab changes. ModuleScienceLab got new options, and there's also a new ModuleScienceConverter.

I like the idea of Kanddak's module making the end rings toggleable instead of having two of each module. With CKAN, extra dependencies is a non-issue, and you could just make it optional with a modulemanager config. I'm tempted to incorporate this module into my current playthrough.

That's all I have for now, since I've yet to unlock composites in my current playthrough. I'm now thinking about writing a modulemanager config to patch TechRequired as a temporary solution to play the game like I want to.

[VenomousRequiem]

You may have addressed this already, but what about a PMA style adapter? Like one that tapers from 1.25 metres into .625 metres? That way I can use this with Tantares to make the ISS.

[sharpspoonful]

You can tweakscale the ring cap to do this

[Moon Goddess]

I can very easily afford a new laptop right away on my salary, but I don't like the current offerings that come with Windows 8 (personal experience, recommendation of family, friends and colleagues from academia/engineering). I know I can buy a downgraded Win 7 / Win 8.1 machine now and upgrade it to Win 10 later, but since Win 10 will require new drivers/BIOS/etc. to take advantage of its underlying features, I decided that it was best to wait until the Win 10 RTM in June/July and invest in a better machine then.

Wanted to throw in my personal experience of running 8.1 and 10 Beta on my present machine (switching for testing purposes) and haven't found anything on modern hardware that needed updated drivers. (I have no run KSP on windows 10 though) But we're kinda expecting mid July at this point so not too bad of a wait.

- I'm not sure about having the ability to dynamically patch over the side recesses on the nodes; the KarmonyNodeCover models were considered a concession part made available to users, and not really something I'd recommend for regular use

I've never quite understood your objection here,

I've heard you say that it's unrealistic to be cutting thru or welding shut a bulkhead, which I completely agree with...

But I've never seen the VAB as an actual vehicle assemble out of premade lego pieces. That's even more unrealistic, to me the VAB has to be analogous to a CAD program. Spacecraft are all custom affairs built to purpose from the ground up.

So in my eyes if I grab a Karmony module, and leave it as is, I'm requesting the factory build a pressure bottle with 6 holes in it, but if I grab a karmony module, and cover 2 of the nodes with nodecovers I'm requesting the factory to build a pressure bottle with 4 holes in it, those other holes aren't being welded shut there were never holes to begin with.

In my eyes, the "RP" of it is exactly the same if it's a part that you slap covers on, a part that you use right click to change the model of, or a series of 5 different part combinations that you pic the one you want, in universe the factory builds resulting configuration the same way.

So in that light, what would be the objection to the right click method?

[larkvi]

I personally agree with Moon Goddess' point, and would be very interested in being able to disable nodes I am not using, to make stuff look nicer. Is this a problem with it no longer matching the IVA? (I don't really use IVAs, personally)

I have been playing with the new version with its dependencies installed, and I am noticing an issue with overlapping textures where the modules meet, which is a little ugly. I don't know if this is the kind of issue you want reported. Album showing it happening here: http://imgur.com/a/GWWmI#0

[sumghai]

Is there a reason all parts have TechRequired = composites, rather than being grouped along with stock parts of similar functionality? I like the idea of building my station incrementally as I progress through the tech tree. Having all station modules under a single tech node kinda removes the point of playing career.

I put them all in the same later-game tech node because FusTek parts are intended as high-quality "end game" station modules based around a special construction technique.

They're currently in the composites node, but ultimately, if and when tech tree modding becomes a possibility, I'd like to create my own node called "Whipple Shielding" - this is because FusTek modules are constructed by bolting on protective panels offset ~80mm from the internal pressure vessel walls and the space filled with insulation, which offers lightweight but excellent MMOD protection.

The science module isn't updated for the 1.0 science lab changes. ModuleScienceLab got new options, and there's also a new ModuleScienceConverter.

Thanks for the heads-up - I'll push a commit with the fix in ten minutes' time.

I like the idea of Kanddak's module making the end rings toggleable instead of having two of each module. With CKAN, extra dependencies is a non-issue, and you could just make it optional with a modulemanager config. I'm tempted to incorporate this module into my current playthrough.

I hereby confirm that end rings on the Habitat, Logistics, Science, Utilities, Warehouse and Payload Bay modules will be toggleable (with mass/cost differences).

The Kupola and Kuest airlocks will continue to only come with tapered ends, since they have always been intended as standalone modules.

You may have addressed this already, but what about a PMA style adapter? Like one that tapers from 1.25 metres into .625 metres? That way I can use this with Tantares to make the ISS.

I personally feel that the 0.625 docking ports are too small for crew transfer, so I don't plan on making a PMA-style adapter.

- I'm not sure about having the ability to dynamically patch over the side recesses on the nodes; the KarmonyNodeCover models were considered a concession part made available to users, and not really something I'd recommend for regular use

I've never quite understood your objection here,

I've heard you say that it's unrealistic to be cutting thru or welding shut a bulkhead, which I completely agree with...

But I've never seen the VAB as an actual vehicle assemble out of premade lego pieces. That's even more unrealistic, to me the VAB has to be analogous to a CAD program. Spacecraft are all custom affairs built to purpose from the ground up.

So in my eyes if I grab a Karmony module, and leave it as is, I'm requesting the factory build a pressure bottle with 6 holes in it, but if I grab a karmony module, and cover 2 of the nodes with nodecovers I'm requesting the factory to build a pressure bottle with 4 holes in it, those other holes aren't being welded shut there were never holes to begin with.

In my eyes, the "RP" of it is exactly the same if it's a part that you slap covers on, a part that you use right click to change the model of, or a series of 5 different part combinations that you pic the one you want, in universe the factory builds resulting configuration the same way.

So in that light, what would be the objection to the right click method?

I personally agree with Moon Goddess' point, and would be very interested in being able to disable nodes I am not using, to make stuff look nicer. Is this a problem with it no longer matching the IVA? (I don't really use IVAs, personally)

As mass-produced products, FusTek Station Parts aren't intended to see a lot of customisation - customisation drives up costs.

I'm planning to allow the toggling of tapered end rings because said end rings don't actually influence the design of the main pressure vessel of the modules.

As for the Node modules, no, they don't have IVAs. However, their pressure vessels were designed and certified with the recesses in mind. If you asked for a rework of a node module with 1~4 of the recesses covered up with panels, while internally retaining the hatch frames (albeit with no hatches), then that's understandable. But if the recess-covering rework involved actually taking out the corresponding internal hatch frames and replacing them with curved internal pressure walls, the modules will need to be recertified due to the fundamental change in their internal structure, which would drive up costs.

The other reason I've adamant about the recesses is because by blocking them off, you're denying yourself future expandability of your station (an edge-case argument could be made for ground bases, where a node lying on its side on a planet's surface would never need the bottom-facing hatch opened).

So, here's how I intend to handle the recesses:

- In the VAB/SPH, you can manually cover them up using the two different node covers, as of right now.

- KIS 1.1.x now offers stack attachment of parts in EVA, so if you decide to replace a node cover with a docking port (or vice versa), you will be allowed to do so in EVA.

I have been playing with the new version with its dependencies installed, and I am noticing an issue with overlapping textures where the modules meet, which is a little ugly. I don't know if this is the kind of issue you want reported. Album showing it happening here: http://imgur.com/a/GWWmI#0

It looks like in many of the cases, you're trying to stack Kupola and Kuest airlock modules on flat ended modules using part clipping. Again, I'll point out that the Kupola and Kuest modules are intended to be separately-docked station compartments.

[SebFierce]

You may have addressed this already, but what about a PMA style adapter? Like one that tapers from 1.25 metres into .625 metres? That way I can use this with Tantares to make the ISS.

I think it's pretty canon and also enforced by CLS that 0.625 hatches are too small for Kerbals to pass through.

(Part of the reason I prefer the HGR Soyuz parts over Tantares ones, the latter feel too small in a lot of cases)

[zyp]

I put them all in the same later-game tech node because FusTek parts are intended as high-quality "end game" station modules based around a special construction technique.

They're currently in the composites node, but ultimately, if and when tech tree modding becomes a possibility, I'd like to create my own node called "Whipple Shielding" - this is because FusTek modules are constructed by bolting on protective panels offset ~80mm from the internal pressure vessel walls and the space filled with insulation, which offers lightweight but excellent MMOD protection.

I'm not opposed to having them late in the tech tree, but I don't like the all or nothing aspect of having everything in the same tech node. Stations are launched in parts and evolve over time, so it makes sense to start with something like a basic habitat, and then you unlock more functionality for your station later.

Compare this to your Service Module System (which I'm also playing with and enjoy) that have the parts spread across a lot of nodes, even though they're designed to be used together on a single launch.

- KIS 1.1.x now offers stack attachment of parts in EVA, so if you decide to replace a node cover with a docking port (or vice versa), you will be allowed to do so in EVA.

I've been planning to do exactly this. My node modules will be launched with extra hatches installed for possible future expansion but covered up until they are needed, and then I can do spacewalks to remove the cover panels and install the necessary docking hardware. I agree completely with having the end rings toggleable but the side nodes fixed.

Speaking of KIS, have you thought about making a module with a large volume container with EVA access? Considering the volume limits on the containers, just sticking a bunch of the small containers into the warehouse module isn't very practical.

Since KIS can do containers with internal-only access, the logistics module should probably be one. That way kerbals can go there to pick up parts to bring along on a spacewalk. This is of course limited to parts that's small enough to fit in a kerbal's own inventory.

[Master Tao]

They're currently in the composites node, but ultimately, if and when tech tree modding becomes a possibility, I'd like to create my own node called "Whipple Shielding"

Take a peek at Squad/Resources/TechTree.cfg. Module Manager can edit it since 2.6.2.

[sharpspoonful]

I'm not opposed to having them late in the tech tree, but I don't like the all or nothing aspect of having everything in the same tech node. Stations are launched in parts and evolve over time, so it makes sense to start with something like a basic habitat, and then you unlock more functionality for your station later.

Compare this to your Service Module System (which I'm also playing with and enjoy) that have the parts spread across a lot of nodes, even though they're designed to be used together on a single launch.

I've been planning to do exactly this. My node modules will be launched with extra hatches installed for possible future expansion but covered up until they are needed, and then I can do spacewalks to remove the cover panels and install the necessary docking hardware. I agree completely with having the end rings toggleable but the side nodes fixed.

Speaking of KIS, have you thought about making a module with a large volume container with EVA access? Considering the volume limits on the containers, just sticking a bunch of the small containers into the warehouse module isn't very practical.

Since KIS can do containers with internal-only access, the logistics module should probably be one. That way kerbals can go there to pick up parts to bring along on a spacewalk. This is of course limited to parts that's small enough to fit in a kerbal's own inventory.

I do believe it was stated before that the warehouse module will have this capability. It makes no sense for a kerbal to automatically be able to pull parts through the Whipple shield, aluminium, and not depressurize the whole station.