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

[sumghai]

Progress Report, 10 December 2014

IVAs still progressing at a glacial rate, due to problems I'm having with JSIActionGroupSwitch and making multiple instances of the viewport props toggle independently.

That being said, to alleviate concerns, here are some more nice pictures:

Fig 81 - (WIP) FusTek Internals (7)

Fig 82 - (WIP) FusTek Internals (8)

[Buzzou]

looking awesome, i can't wait to see what will go in those racks

[wasmic]

I have also been experiencing lag with the IACBM's. I am running version X0.04-4. My suspicion is that the ligh modules might cause the lag (since there's a lot of lights per IACBM). However, the lag is also there when the lights are off.

[Starwaster]

Actually, try re-installing FAR now.

The commit that contains the fix for FAR and the payload bay module essentially requires the player to clear out / reset their CustomFARClassification file. Perhaps that was all that was needed in your case

Loading, saving and reloading existing craft with those modules can also help. (after updating)

That's also good generic advice anytime you're dealing with altered PartModules

[fusty]

Gorgeous work!

[sumghai]

Christmas break was a rather busy time for me, as I continued to slog on with my thesis and a few other commitments. In addition, I accepted a job offer in Christchurch, and so I will be relocating there at the end of the month.

This means that I will no longer have access to my usual dev PC, and be relegated to add-on authoring from my (vastly inferior) laptop - while I can still model/texture/configure parts, I won't be able to run even a minimal installation of the game. I'm hoping to upgrade to a better laptop soon, but that will have to wait until I've settled down.

But anyways...

Progress Report, 15 January 2015

Once again struggling with a modder's block with regards to the viewport shutters, I decided to look at what other things I wanted to do for R0.04a.

As always, finishing the IVAs is my top priority, and so I took some time to revise the FLEXrack drawer arrangements based on Figure 75 from last year:

Fig 83 - (WIP) FusTek IVA Panels Development Process 4

Because of all this planning and re-planning, I discovered that practically all of the FLEXracks will use the same three horizontal closeout panels around the custom-tailored lockers/drawers. I'll modify the existing FLEXrack props to include the closeouts, which means one less prop file I'll have to deal with in the long run.

Another thing I've been looking at for R0.04a is a proper propulsion trunk for the FusTek Resupply Module. In the past, I recommended the Service Module from the SDHI SMS pack for this purpose, but with the addition of the umbilical, it now clips hideously into the smooth clean panelwork on the Resupply Module. The design of the new Resupply Module propulsion trunk was inspired by both JAXA's H-II Transfer Vehicle and Orbital Sciences Corporation's Cygnus, in that it would be a stubby, cylindrical tank with tapers. Foil insulation would be used to visually distinguish the trunk from the standard FusTek aesthetic.

Other considerations I made whilst designing the ATV propulsion module include:

- An unpressurized carrier compartment to allow an "enhanced" FusTek Resupply ATV spacecraft to, in additional to the usual Kerbalnaut care package, carrying into orbit up to two (2) FusTek FLEXracks. This will be relegated to R0.05a, since I'll be concurrently developing the FusTek FLEXrack system as a separate add-on by that time.

- Although I do plan on making large PV Solar Arrays for FusTek space stations itself, I don't have any immediate plans to make smaller PV Solar Panels for the ATV. I want people to have the flexibility to configure their ATVs, just like they are free to choose what solar panels / RCS thrusters will go on their SDHI Service Module.

- The ATV main engine might probably be recessed inside the rear of the propulsion trunk itself. This will allow the bottom of the ATV to sit flush on top of fairing shroud decoupler bases (such as those from KW Rocketry or my hypothetical SDHI AeroFairings add-on)

Fig 84 - FusTek Resupply ATV concepts

[sharpspoonful]

I have also been experiencing lag with the IACBM's. I am running version X0.04-4. My suspicion is that the ligh modules might cause the lag (since there's a lot of lights per IACBM). However, the lag is also there when the lights are off.

This is something that has been proven to not be true. While admittedly, i believe the IACBM cause lag in large numbers, it has nothing to do with the light modules. My guess is either colliders or meshes. But lights were empirically ruled out as the cause of lag.

[Sampa]

Very cool stuff, just downloaded the last updated version to try and see if I like it better than Bobcat's ISS Community and Mir Packs!

[hipy]

Already posted by some people but I found out the following: when 2 modules get near eachother the lag is insane(on the scale of unplayable). I tried with stock docking ports and still had this problem. So it's not the docking ports that causes the lag.

[sumghai]

Already posted by some people but I found out the following: when 2 modules get near eachother the lag is insane(on the scale of unplayable). I tried with stock docking ports and still had this problem. So it's not the docking ports that causes the lag.

I've responded on the GitHub issue tracker.

[Sampa]

some ATVs, that's a BRILLIANT idea!

[InsaneDruid]

Sorry if it was asked before: could you PLEASE fix the UV-Mapping of both the warehouse and payload modules "module_id_symbol"?

While the other ones (hab/science etc) are mapped to a 256*256 part of the main texture (to avoid ugly seams) the ones of the warehouse and payload module are off, so that you need a 257*257 part of the main texture to have aligning texture parts on the main skin and the icon skin (and either shrinking it to 256*256 for power of two textures or leaving it as 257*257). This can be seen on the default and alt textures, as the bump map is off one pixel at most of the modules.

While it can be worked around for the warehouse, especially the layout of the payload module is a skinners nightmare. PLEASE delete one side (or both, as they don't align with the other modules icons anyway) or make two separate uv maps for the left and right side. PLEASE!. You already needed to flip the text 90 degree to work around the mirroring, but you can't mirror normal maps (as the normals on eeither side NEED to be different). I am making a skin that uses high detailed normalmaps, and you cannot avoid the most ugly seams on one side of the payload module, as the normal map gets mirrored. The icing on the cake is that the uv layouts of both sides don't align, so one side is mirrored AND shifted by several pixels. Again: not aproblem for plain "one color" skins, but the worst nightmare for a detailled skin.

PLEASE!

I would fix it myself but somehow the blender .mu export fails on the fustek parts.

PS: dont get me wrong, if i would not love the parts i would not ask^^

Edited March 7, 2015 by InsaneDruid

[Deltervees]

Could someone please direct me to the most recent DL link? I can't find it.

[Mecripp]

Could someone please direct me to the most recent DL link? I can't find it.

Here you go it should be the one https://github.com/sumghai/FusTek_StationParts/

[Stone Blue]

Sumghai... I just read the post above on the ATVs...

You should take a look at the thread I just posted last night...It links a couple articles you should read on the Jupiter/Exoliner concept...

http://forum.kerbalspaceprogram.com/threads/113035-How-about-a-Jupiter-Exoliner-Centaur-parts-mod

[sumghai]

You should take a look at the thread I just posted last night...It links a couple articles you should read on the Jupiter/Exoliner concept...

Thanks for the info.

However, as I've stated, I'm already basing my ATV propulsion trunk on the H-II Transfer Vehicle and Cygnus designs.

Another thing I've been looking at for R0.04a is a proper propulsion trunk for the FusTek Resupply Module. In the past, I recommended the Service Module from the SDHI SMS pack for this purpose, but with the addition of the umbilical, it now clips hideously into the smooth clean panelwork on the Resupply Module. The design of the new Resupply Module propulsion trunk was inspired by both JAXA's H-II Transfer Vehicle and Orbital Sciences Corporation's Cygnus, in that it would be a stubby, cylindrical tank with tapers. Foil insulation would be used to visually distinguish the trunk from the standard FusTek aesthetic.

[Mecripp]

How you are doing the inside have you thought about doing it to the outside so we could grab parts and change them out guessing it's going to be along time before we can do anything in IVA ?

[sumghai]

How you are doing the inside have you thought about doing it to the outside so we could grab parts and change them out guessing it's going to be along time before we can do anything in IVA ?

I cannot understand this run-on sentence.

Please rephrase your request.

[Mecripp]

Sorry making the racks on the outside like you are doing on the inside.

EDIT- Then a kerbal could change out a panel if needed

We could have life support panels and what not.

O happy Kerbal can't Wait hehe

Edited March 15, 2015 by Mecripp2

[sumghai]

Sorry making the racks on the outside like you are doing on the inside.

EDIT- Then a kerbal could change out a panel if needed

We could have life support panels and what not.

Ah, I see what you mean now.

Yes, external FLEXracks are planned for R0.05a - see this May 2014 blog entry for my ideas and musings:

http://forum.kerbalspaceprogram.com/entries/1487-FLEXrack-and-FusTek-integration-Ideas-and-Musings

[B4rberblacksheep]

Ohhh man that sounds awesome

[wasmic]

By the way, congrats with the 100 pages!

[sumghai]

Ohhh man that sounds awesome

Additionally, I'm currently adopting a wait-and-see approach with regards to the actual implementation of the external FLEXracks, since I hear that the features it needs from KAS may soon be migrated to KIS.

By the way, congrats with the 100 pages!

Haha, thanks

---

(I can't believe you had the gall to pass this off as a) Progress Report, 18 March 2015

As many of you may be aware, I've moved to Christchurch to start a new job there, which means instead of my nice office PC at uni, I'm now relegated to using a horrifyingly-underpowered second-hand 2005~esque laptop - this means I'm currently unable to run KSP at all in order to test models/parts. I do plan on buying a better laptop soon, though.

In the meantime, InsaneDruid has made some really awesome alternative textures, which I'm planning on including into the main parts pack itself. I've set up his GitHub account as a contributor, so that he can easily push updates/fixes to his textures at any time.

Druid and I are still going over his work, but from I what I see, he's done something extremely clever with his MM patches that allow his part pack to be dynamically inserted into an existing list of alternative textures without overwriting anything. If this works out well, it would make it extremely easy for people to install/uninstall any number of alternative skins without messing around with CFGs themselves.

Oh, and er Druid, I got your report regarding the misaligned module ID symbol textures. I'll look into it once I've finished my contract work for RealChutes

[sumghai]

Progress Report, 28 March 2015

Number of days without a KSP-runnable laptop: 59

I've integrated the MLI Blankets officially into the FusTek repo on GitHub.

Because in the future, users are likely to have any combination of alternative texture packs, I decided that rather than manually editing the main FusTek_MMPatch_TextureSwitch.cfg patch each time a new texture pack is added/removed, I've sought InsaneDruid's advice and made the patches modular - basically, each texture pack subfolder will include its own MM Patch (e.g. MLI_Blankets.cfg, KSO.cfg), which will use regular expressions to append themselves to the main FusTek_MMPatch_TextureSwitch.cfg patch.

Since I'm currently unable to test these CFG file edits, could I please have some volunteers to do the following?:

- Download and install latest experimental version of FusTek from the GitHub repo

- Start KSP

- In the VAB/SPH, grab FusTek parts and see if you can change the textures between FusTek Classic / KSO Phase II / MLI Blankets

- Close KSP

- Remove the KSO.cfg temporarily

- Restart KSP

- In the VAB/SPH, grab FusTek parts and see if you can change the textures between FusTek Classic / MLI Blankets

- Close KSP

- Remove the MLI_Blankets.cfg temporarily and re-add KSO.cfg

- Restart KSP

- In the VAB/SPH, grab FusTek parts and see if you can change the textures between FusTek Classic / KSO Phase II

- Close KSP

- Remove both MLI_Blankets.cfg and KSO.cfg

- Restart KSP

- In the VAB/SPH, grab FusTek parts and see if the only texture option available is FusTek Classic

Let me know if there are any issues or if I broke the CFG patches

[Mecripp]

Progress Report, 28 March 2015

You Broke it only got the one can't change to any of them.

EDIT- Isn't that what his did ?

@PART[iACBM125m]

{

@MODULE[FStextureSwitch2],0

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/IACBM_1.25_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/IACBM_1.25_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[iACBM25m]

{

@MODULE[FStextureSwitch2],0

{

@textureNames ^= :$: ;FusTek_Retexture/MLI_Blankets/IACBM_2.5_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/IACBM_2.5_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[iACBM*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_common_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_common_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTek*]

{

@MODULE[FStextureSwitch2],0

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_common_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_common_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekResupplyModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_resupply_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon2_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonyHabModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_hab_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonySciModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_sci_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonyStorModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_stor_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonyUtilModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_util_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonyWarehouseModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_warehouse_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon3_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

@PART[FusTekKarmonyPayloadBayModule*]

{

@MODULE[FStextureSwitch2],1

{

@textureNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon_payload_texture:

@mapNames ^= :$:;FusTek_Retexture/MLI_Blankets/fustek_station_icon4_bump_NRM:

@textureDisplayNames ^= :$:;MLI Blankets:

}

}

Edited March 28, 2015 by Mecripp2