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

[Sochin]

The Bio Sample locker should have warning stickers saying DO NOT EAT CONTENTS - NOT FOR SNACK STORAGE

[Starwaster]

The Bio Sample locker should have warning stickers saying DO NOT EAT CONTENTS - NOT FOR SNACK STORAGE

Which can be opened up, revealing snacks alongside the samples in spite of the warning!!!

[sumghai]

The Bio Sample locker should have warning stickers saying DO NOT EAT CONTENTS - NOT FOR SNACK STORAGE

Which can be opened up, revealing snacks alongside the samples in spite of the warning!!!

LOL. Noted!

---

(Not Really Making) Progress Report, 29 June 2014

Had to take another end-user mandated detour to deal with GitHub Issue #26, as the result of user complaints with regards to game performance and IACBM lights

Reducing spotlight transforms to decrease lag

As was mentioned, the IACBMs have a total of eight spotlight transforms - two red, six white - each corresponding to a LED illuminator mesh on the docking port itself.

I was initially reluctant to take out half of the lights and reposition the remainder, since this would mean the light is (unrealistically) coming out of the latching control box rather than the LED lamps on either side; however, after a little bit of tweaking, the results seemed acceptable. I didn't notice any performance differences from this change, but that was because I didn't have time today to test them on a larger station*.

*In case you're wondering, I haven't had time to actually play the game since working on X0.04, and the example station I built in R0.03.5a had already been deorbited.

IACBM lights don't reach very far

This is intentional - the IACBM docking port lights are only meant to be orientation indicators, and not for general illumination. The Unity spotlight objects are simply used to add a nice glow to the inner surface of the docking ports.

ModuleLight replacement / removal

I do agree with users when they suggest that toggling the Lights action group shouldn't turn on all the IACBM lights on a station/vessel (especially ports already docked together), and replacing ModuleLight with FSanimateGeneric seemed to work...except that this now means that if the station/vessel runs out of ElectricCharge, any IACBM lights turned on will still be left running, since FSanimateGeneric does not support resource comsumption.

I have the feeling that users will either simply have to remember to unassign the IACBM lights from the Lights AG, or someone would need to write a new animation module that includes resource consumption in the deployed state and reverts if said resource is depleted. The former option is easiest for me and less convenient for users, whilst the latter would be easier for most users (since they don't need to remember to unassign the Light AG) but I would then get flak for bloating up people's GameData with yet another "useless" dependency.

[sharpspoonful]

LOL. Noted!

---

(Not Really Making) Progress Report, 29 June 2014

(...). As was mentioned, the IACBMs have a total of eight spotlight transforms - two red, six white - each corresponding to a LED illuminator mesh on the docking port itself.

I was initially reluctant to take out half of the lights and reposition the remainder, since this would mean the light is (unrealistically) coming out of the latching control box rather than the LED lamps on either side; however, after a little bit of tweaking, the results seemed acceptable. I didn't notice any performance differences from this change, but that was because I didn't have time today to test them on a larger station*.

*In case you're wondering, I haven't had time to actually play the game since working on X0.04, and the example station I built in R0.03.5a had already been deorbited.

...whilst the latter would be easier for most users (since they don't need to remember to unassign the Light AG) but I would then get flak for bloating up people's GameData with yet another "useless" dependency.

Sumghai. Stop giving in to these silly requests. I'd actually suggest taking down the Released thread, and leaving the DL in the Dev thread. People seem to think that this mod is "finished" and are gripping about silly things. Look at the Kerbin Orbiter mod. That thing has 4 dependencies, plus custom ATM and BolderCo folders that make the parts look marginally nicer at the expense of my poor GPU. You have 4 lightweight dependencies: Firespitter (who doesn't nowadays?), MFT, (which also is a "soft dependency, so to speak, because the resupply module is useless with out TAC-LS) CLS, and Ship Manifest. The needed plugins are not resource demanding, nor are the difficult to use, and make ship-to-ship and compartment-to-compartment transfer easier on all vessels.

The ICBM issue is real, but not game-breaking unless you are building a uselessly large station, If that's the case, the can use the stock docking ports.

Also: It doesn't take that long to unassign lights in the VAB. That is a client-side issue.

TL;DR

Haters gonna hate. You do you, Boo. Finish the mod how you see fit, fix major bugs, polish later.

Edited June 30, 2014 by sharpspoonful

[falken]

Suggestions were made, nothing more... No need to blow it out of proportion.

[sharpspoonful]

I'll retract this statement. My apologies, falken.

Edited July 2, 2014 by sharpspoonful

[sumghai]

Progress Report, 30 June 2014

Closed GitHub Issue #26, with the following summary:

1.25m IACBM

- Reducing the number of light transforms to one red and three white did not result in any noticeable performance increase

- On the other hand, this results in the visually inaccurate situation of light essentially coming out of the latching controller mesh

- Reverted to two red / six white light transforms

- Reduced range and intensity, as these lights are not for general illumination

2.5m IACBM

- Reducing the number of light transforms to one red and three white did not result in any noticeable performance increase

- As latching controller mesh is far away from the light transforms, the resulting effect is acceptable

- Reduced range and intensity, as these lights are not for general illumination

Additional notes

- ModuleLight is still required to account for ElectricCharge consumption / lights off when power-deprived; removal is strongly discouraged

- Users should manually unassign the IACBM lights from the Lights Action Group

- Alternatively, it would be nice if someone donated a simple PartModule that can be added to the IACBMs to automatically prevent ModuleLight from being assigned to the Action Groups; this could come in the form of a lightweight bespoke plugin that will be included in the FusTek pack by default

Also:

- I've decided to make some of the ASET props as standard for the internals; I'll speak to Alexustas about this, and I'll try to make my own internal panels match the ASET art style, if possible.

- I'll soon strip out the emissive windows on the Karmony Modules themselves, since I'd like to make the windows transparent using the JSITransparentPod PartModule Mihara wrote for me.

- Time to have lunch

Edited June 30, 2014 by sumghai

[jebandhisfriends]

can you please add landing legs for these modules ??

[Railgunner2160]

Try letting him finish the things first...

[Kanddak]

Sumghai, I salute your amazing responsiveness to user requests of this nature. Thank you for looking into the lights.

[Sudragon]

Just looking at the IVA development concept... what happens when the hab module is being used in a ground base? Do kerbals sleep standing up?

[StEligius]

Just looking at the IVA development concept... what happens when the hab module is being used in a ground base? Do kerbals sleep standing up?

It's a Murphy bed when not in Zero G, lulz, JK!

[sumghai]

hey guys

when are you going to add some new parts?? like ground base parts for interplanetairy stations?

can you please add landing legs for these modules ??

The official release date for all upcoming features has been confirmed as the following:

When It's Doneâ„¢

Just looking at the IVA development concept... what happens when the hab module is being used in a ground base? Do kerbals sleep standing up?

It's a Murphy bed when not in Zero G, lulz, JK!

Unfortunately, the Habitation Module IVA configuration is primarily designed for space stations, so yes, Kerbals would end up sleeping upright. I have entertained the concept of a dedicated habitat variant for planetary surfaces, but that's for the distant future.

Besides, perhaps Kerbals normally

anyway

---

Progress Report, 3 July 2014

Alexustas has granted me permission to reuse his ASET props pack, noting users will need to download the props directly from him. Most of these, such as RPM MFDs, EVA handles, fire extinguishers, beverage sachets etc can be used as-is, while others, such as the flight manual, may require me to make FusTek specific variants (since they have ASET logos on them).

As I would still need to make the internal panels and drawers myself, I've been studying extracted models and textures from the ALCOR pod IVA. I've noted that ASET internals tend to use noticeably more photorealistic bare metal components, screws and fittings against a slightly textured and off-white background. Since I've envisioned that the panelings more closely resemble the clean white USOS internals on the ISS and the Shuttle Middeck Lockers, some mental juggling may be required before I can decide how to proceed.

I've also noticed that there's a prop for a JSI RPM rack-mounted computer, with somewhat peculiar dimensions - I'll need to decide whether to make my own computer unit in the standard* drawer size, or an adapter plate that would accommodate the existing units inside a wide* drawer size.

*Proper names for the drawer/panel size variants (w x h mm).

- Standard = 250 x 190

- Wide = 500 x 190

- Tall = 250 x 380

- Big = 500 x 380

[Kanddak]

Unfortunately, the Habitation Module IVA configuration is primarily designed for space stations, so yes, Kerbals would end up sleeping upright. I have entertained the concept of a dedicated habitat variant for planetary surfaces, but that's for the distant future.

If you ever go down this road, this reminds me of a wild blue-sky idea I had a while ago: Develop a plugin that allows one part to have several possible IVAs, chosen by a tweakable. That would allow the creation of a lot of different mission modules without flooding the part menu. For another example besides surface-base variants, a very large station might want further specialization of modules, like a dorm module with 8 sleep stations, a dedicated sickbay, etc -- I'm thinking of http://www.nmstarg.com/2012/09/the-city-in-sky.html . The modular nature of the panels you're making now seem to be a good foundation for eventually doing this.

[Tcy16]

If you ever go down this road, this reminds me of a wild blue-sky idea I had a while ago: Develop a plugin that allows one part to have several possible IVAs, chosen by a tweakable. That would allow the creation of a lot of different mission modules without flooding the part menu. For another example besides surface-base variants, a very large station might want further specialization of modules, like a dorm module with 8 sleep stations, a dedicated sickbay, etc -- I'm thinking of http://www.nmstarg.com/2012/09/the-city-in-sky.html . The modular nature of the panels you're making now seem to be a good foundation for eventually doing this.

I think that the firespitter plugin can do this already, though i am absolutly not sure. (If some does know, please corect me if im wrong )

[Mihara]

...Well, if Firespitter doesn't do it, that would be a perfect addition to RPM. I'll look into it when I get a chance.

Might even make it possible to have IVAs tech level dependent -- I've added techlevel restriction for individual pages, but not for IVAs as a whole.

[sumghai]

this reminds me of a wild blue-sky idea I had a while ago: Develop a plugin that allows one part to have several possible IVAs, chosen by a tweakable. That would allow the creation of a lot of different mission modules without flooding the part menu. For another example besides surface-base variants, a very large station might want further specialization of modules, like a dorm module with 8 sleep stations, a dedicated sickbay, etc -- I'm thinking of http://www.nmstarg.com/2012/09/the-city-in-sky.html . The modular nature of the panels you're making now seem to be a good foundation for eventually doing this.

I think that the firespitter plugin can do this already, though i am absolutly not sure. (If some does know, please corect me if im wrong )

...Well, if Firespitter doesn't do it, that would be a perfect addition to RPM. I'll look into it when I get a chance.

The Firespitter plugin can swap textures and/or meshes, but only on the external model. (Incidentally, I have been thinking about using FStexture switch to reduce VAB/SPH part list bloat by allowing toggling between tapered and non-tapered part variants, although the fact that the recessed tapered ends have multiple mesh colliders may make things a bit more difficult - I'll experiment with this idea later today).

A single part that can switch between module specializations isn't really possible, since you're effectively asking for each specialization to dynamically load/unload PartModules at run time (e.g. Science Lab, different TAC LS configs).

As for having a hab that can switch between horizontal and vertical beds, that's not really possible given the current viewport configuration.

EDIT: See GitHub Issue #27

Edited July 4, 2014 by sumghai
Opened GitHub issue for suggestion

[sumghai]

Progress Report, 5 July 2014

Consolidating Tapered / Flat-ended versions into one part (GitHub Issue #27)

This didn't turn out so well, and I ultimately scrapped the idea.

Initial testing with FSmeshSwitch seemed promising, where the two Hab module variants with different end styles were consolidated into one part, with the taper being toggleable. Unfortunately, this was only a visual effect, as FusTek makes use of multiple mesh colliders to make the recessed docking port areas, something FSmeshSwitch could not handle at all.

Specular Shaders

A while back, nothke made some alternative texture packs for FusTek Station Parts R0.03.5a, and made some (less-than-diplomatic) criticisms regarding the lack of a specular shader on my models.

Since then, he has failed to respond to my repeated requests for what specular settings he desired, so eventually, I decided to just wing it and slap something together. This results in a nice shine to the current models, which fortuitously also lessened the pixelated effect on the admittedly-boneheaded textures I have in the current X0.04-4 release (to be fair, I was trying to preserve fusty's original aesthetic when I first started this expansion/maintenance project).

I'll adapt nothke's texture packs for R0.05a - for now, I'm just future-proofing my upcoming R0.04a release.

Experimental plugin to automatically unassign IACBM lights from action groups

ModuleLight is required for the IACBM lights to correctly calculate ElectricCharge consumption.

ozraven has been working on an (strictly optional) convenience plugin that can manipulate PartModules and action groups - one demonstrated usage is automatically unassigning the LED illuminators on the IACBM docking ports, so that if you toggle the Lights AG from the flight scene, your station won't completely light up like a bonfire from all the IACBMs you have on your station (Plugin / dependency minimalists can, of course, simply remember to do this un-assignment manually )

Karmony Viewports now also transparent

Whilst dealing with the ModuleLight issues with the IACBM, I recalled that the Karmony Hab / Sci / Utilities Modules had light-up viewports that only used emissive textures. As I continue to make (glacial) progress with the IVAs, I decided that I wanted the (toggleable) light to actually come from the IVA and not the fake glowing viewports in the current release.

As such, I modified some of the model files with interchangeable panels / viewport cutouts, such that essentially, one can now look through the viewports on the Karmony modules from the outside of the station / vessel and see the Kerbals inside. The little windows on the Karmony hatches didn't receive the same treatment, as the the cutouts required would have affected too many other primitives and they were too small to warrant such attention anyway.

Fig 70 - FusTek Station Parts - (Upcoming) Visual Tweaks

Karmony Node Cover may lose Viewport variant

I've been thinking about removing the viewport variant of the Node Cover, now that the viewport primitive itself is transparent. This is because the Node modules aren't actually occupied by Kerbals, only traversable, and there's not much point sticking a see-through window on a part you'll never see Kerbals inside anyway.

Thoughts?

[MOARdV]

(... snip a bunch of things ...)

Thoughts?

It depends. My chief concern about making the viewports transparent, based on what I understand you saying, is that you're increasing the model complexity by adding an IVA that's rendered to each of those modules chiefly to allow you to use interior lights to light up the viewport. Considering the KSP lighting model doesn't do self-shadowing very well (if at all), I'd expect the net effect being that the parts with interior lighting cause everything around them to glow.

For the cupola part, I can see making the change, since it has large viewports already. For the cylindrical parts? Those viewports are small, and it seems like the payoff on the change is pretty small. I'd have to see it in-game, and see what the performance impact is, before I could say for sure, but based on my experience with KSP, I think sticking to emissives would be the better choice for portholes.

[falken]

Maybe give a choice of with and without.

Is there any chance of a half size module without the 4 attach points on it?

[Starwaster]

Transparent pod OMG!!!!

SHUT UP AND TAKE MY MONEY!!!!

(well, it's theoretical money, so good luck spending it...)

I've been thinking about removing the viewport variant of the Node Cover, now that the viewport primitive itself is transparent. This is because the Node modules aren't actually occupied by Kerbals, only traversable, and there's not much point sticking a see-through window on a part you'll never see Kerbals inside anyway.

Thoughts?

Uhm please don't do this. Or if you must, replace it with the windowless variety (edit: by this I mean keep change the model so the part / name are still intact) but don't remove it. That will break craft. Although, unless it looks visually unpleasing, I'd say leave it as is no matter if Kerbals are ever seen it it or not.

Here's a thought... hatches / IACBM docking ports with windows. I'm not clear on exactly what has to be done to make that happen as I'm not at all familiar with the plugin. It just seems kinda cool and I thought I'd throw it out on the porch and see if the cat licks it up.

Edited July 5, 2014 by Starwaster

[Neutrinovore]

Karmony Node Cover may lose Viewport variant

I've been thinking about removing the viewport variant of the Node Cover, now that the viewport primitive itself is transparent. This is because the Node modules aren't actually occupied by Kerbals, only traversable, and there's not much point sticking a see-through window on a part you'll never see Kerbals inside anyway.

Thoughts?

Could you conceivably create a spherical inner surface with a static, corrected-perspective view of what the interior would look like? So that, looking in from outside, one would see what appears to be a 3-dimensional interior, but is really just a 2D image on the inside of a sphere. This 'view' would be attached to the VNC (Viewport Node Cover), you understand. I don't know if this would even work, you'd have to work out some way of not seeing or clipping through the surface of the Node Module itself. Meaning that if one doesn't have a VNC installed, you'd see the regular 'hatch' texture that it already has. But if one installs a VNC, it would have to somehow 'override' that section of the texture so that one could see the image of the interior. Hopefully that's clear enough of an explanation to get my point across.

Again, no idea if such a thing is possible or practical, I'm just brainstorming.

Rotsa ruck!

[sumghai]

I've been thinking about removing the viewport variant of the Node Cover, now that the viewport primitive itself is transparent. This is because the Node modules aren't actually occupied by Kerbals, only traversable, and there's not much point sticking a see-through window on a part you'll never see Kerbals inside anyway.

Thoughts?

It depends. My chief concern about making the viewports transparent, based on what I understand you saying, is that you're increasing the model complexity by adding an IVA that's rendered to each of those modules chiefly to allow you to use interior lights to light up the viewport. Considering the KSP lighting model doesn't do self-shadowing very well (if at all), I'd expect the net effect being that the parts with interior lighting cause everything around them to glow.

For the cupola part, I can see making the change, since it has large viewports already. For the cylindrical parts? Those viewports are small, and it seems like the payoff on the change is pretty small. I'd have to see it in-game, and see what the performance impact is, before I could say for sure, but based on my experience with KSP, I think sticking to emissives would be the better choice for portholes.

Having IVA lights for the viewports was merely one of multiple reasons for implementing JSITransparentPod on the Karmony-series modules:

- A while back, I wanted to make the Hab windows light up separately, to represent the four individual sleeping compartments and the galley area; until JSI RPM, this wasn't possible

- I thought it would also be neat to see Kerbals going about their business inside the modules

- It would also be cool to have window shutters that Kerbals can manipulate in IVA; again, this is something that JSI RPM has now made possible

In terms of performance, I had a vessel composed of 30+ Karmony Hab modules with the JSITransparentPod enhancement, with no impact on FPS. Having more internal props shouldn't matter, and even with the internal lighting, I believe I can limit the number / range of the spotlights as to not have any adverse effects. But we'll cross that bridge when we get there.

Uhm please don't do this. Or if you must, replace it with the windowless variety (edit: by this I mean keep change the model so the part / name are still intact) but don't remove it. That will break craft. Although, unless it looks visually unpleasing, I'd say leave it as is no matter if Kerbals are ever seen it it or not.

Actually, I may have a solution to keep the viewport variant for current and future crafts - check back in a few hours.

Could you conceivably create a spherical inner surface with a static, corrected-perspective view of what the interior would look like? So that, looking in from outside, one would see what appears to be a 3-dimensional interior, but is really just a 2D image on the inside of a sphere. This 'view' would be attached to the VNC (Viewport Node Cover), you understand. I don't know if this would even work, you'd have to work out some way of not seeing or clipping through the surface of the Node Module itself. Meaning that if one doesn't have a VNC installed, you'd see the regular 'hatch' texture that it already has. But if one installs a VNC, it would have to somehow 'override' that section of the texture so that one could see the image of the interior. Hopefully that's clear enough of an explanation to get my point across.

This, unfortunately, would be a bit too much work for little gain - I would have to model and texture a fully-fledged IVA for the nodes first, and then do the jiggery-pokery required to project a view of that on the concave surface of a hemisphere.

Here's a thought... hatches / IACBM docking ports with windows. I'm not clear on exactly what has to be done to make that happen as I'm not at all familiar with the plugin. It just seems kinda cool and I thought I'd throw it out on the porch and see if the cat licks it up.

Meow?

All kidding aside, I've pointed out the problem in my previous post:

The little windows on the Karmony hatches didn't receive the same treatment, as the the cutouts required would have affected too many other primitives and they were too small to warrant such attention anyway.

Besides, the Logistics modules doesn't have an IVA, since Kerbal don't sit in them, so the little hatch windows would end up looking into the inner face of the external model with the normals flipped (read: hideous)

Is there any chance of a half size module without the 4 attach points on it?

You mean a half-length Logistics module? We'll see.

[Mihara]

This, unfortunately, would be a bit too much work for little gain - I would have to model and texture a fully-fledged IVA for the nodes first, and then do the jiggery-pokery required to project a view of that on the concave surface of a hemisphere.

Actually, jiggery-pokery could be easy enough. Take a camera, point it at the IVA, kick the projection matrix until it submits.

But yeah, you'd need a full IVA first and I am generally of the opinion that it's better to have nothing visible through windows than seeing an empty IVA through a window when you know someone's supposed to be there.

[sumghai]

Actually, jiggery-pokery could be easy enough. Take a camera, point it at the IVA, kick the projection matrix until it submits.

But yeah, you'd need a full IVA first and I am generally of the opinion that it's better to have nothing visible through windows than seeing an empty IVA through a window when you know someone's supposed to be there.

Indeed

---

(A snack-sized) Progress Report, 6 July 2014

As it turned out, I was able to save the whales the Node Cover Viewport variant by making an extra opaque window pane mesh to sit underneath the usually-transparent viewport frame:

Fig 70 - FusTek Station Parts - (Upcoming) Visual Tweaks 2

I've also removed the lighted window feature from this node cover as well, for obvious reasons.

I'll push these to GitHub in a moment for those of you who want to try things out before R0.04a.