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

[sumghai]

There is an up axis to the airlock door, the light would likely go above the door to avoid collision prospects with a porch/ladder. The only thing the space above may be used for is an awning, which really only makes sense once tornados sprout on Minmus and the base turns into a genuine trailer park.

Now that I think about it, I could have just above the airlock door two white illumination LED banks (two spotlight objects in Unity) plus an animated occupancy indicator (emissive only). This should leave me plenty of room at the sides and the bottom for an optional deck/step ladder/handrails accessory in R0.05a or later.

I'd probably avoid awnings.

Better planning and organization is (IMO) not a setback.

oh, I thought optimizing would be just merging all the parts' textures into a few common ones. But now as far as I can see, you actually made your plating plates modular in texture and mapping as well? And this actually makes adding new textures having to adjust to the dimensions of the plating that you made? Meaning that making something that needs variety like this would look very repeatable, in other words, impossible to make look good:

-snip-

Also the other skin I made, the Kombobulus, relies on having screws positioned in different places on each plate, which your optimization would prevent from happening.

-snip-

I agree that other stuff like doors and windows can be merged. But the actual "skin" (plating) should IMO be cylindrical warped cause it just gives so much possibilities for completely changing the looks of the modules, including allowing to paint something completely different (like maybe.. a coca cola can module =P)

I'd prefer to keep my texture atlases as compact as technically possible, and so heavily make use of common, repeatable elements. From an engineering perspective, it makes sense to have common, modular components (such as the hull plating), only deviating very occasionally when absolutely necessary.

I didn't notice that Unity stretched my 512x1024 textures to square in game (the pixel ratio still looks normal). But also in Unity, there is an option if you open the texture inspector, and make the texture type "advanced" and then "none" in "non power of 2". Now if that actually saves the memory I don't know.

In the absence of further evidence suggesting any benefits from said method, I'm going to leave the setting at its PartTools 0.20 default for now. I don't really want to add another unknown variable to what is turning out to be a rather (unenjoyable) migration.

[sumghai]

Progress Report, 27 October 2013

Had a rather busy week, but I completed the migration of my part authoring workflow to KSP PartTools 0.20, and got most of the (now-optimized) parts back into my KSP installation.

There's not really that much difference in the final parts visually speaking, so no in-game screenshots. However, I do want to raise the following points:

- The latest public version (R0.03.5a) has a total on-disk size of ~20 MB; contrast this with the (current) iteration of my dev build, which is just ~4 MB. I suspect that once loaded in-game, there would be a greater improvement in RAM usage.

- There is something peculiar about the way texture overriding works in KSP 0.20+'s MODEL{} nodes - specifically, if you are trying to override textures by calling from another location, you must already have another set of textures in the same directory as your .MU model files. In trying to use "common" texture/bump/emissive atlases for my parts, I encountered the following dilemma as a consequence of this quirk:

- If I kept each CFG / model organized into individual folders like in R0.03.5a, and then try to make a texture override call to the common atlases in another directory, the parts end up being white and untextured in-game. One workaround would be to put dummy textures in each of the folders, but the prospect of having 80+ "empty" PNGs sitting around is not only unappealing, but would also lead to mass confusion for those attempting to extend my work.

- I could also just put all the CFGs and models in the same directory as the atlases, although it would end up being a bit less organized

After some head-scratching, I opted for the latter, but also decided to bundle all my station parts inside one big "Station Parts Expansion" subfolder under FusTek - this will allow me to do other FusTek projects (like that MSEV) without lumping everything in one big mess inside the main FusTek folder:

Fig 40 - (WIP) FusTek Station Parts - Optimization for R0.04a (4)

- I went from 80+ PNGs down to (currently) nine PNGs, most of which are tiny "swappable" graphics for the Module Icons.

- Another limitation regarding model nodes is that multiple copies of the same animation won't work properly. Originally, I had one animated Viewport model that I hoped to reuse across several of my parts, but KSP's ModuleLight only seemed to recognize the first viewport defined in each model - all subsequent ones remained unlit even after toggling the lights. I ended up making separate model files for each Karmony Mission Module's unique viewport arrangements to ensure all the viewports light up at the same time.

- These new dev parts will break crafts and saves, due to various things I had to do to optimize them, such as tweaking scales and positions in preparation for IVAs.

- The Internals folder is currently empty, as the dev parts will temporarily borrow stock SQUAD IVAs. I'll start working on IVAs for realz in the next dev build.

There's still a fair bit of work to do before I push out the first dev build (X0.04-1):

- The optimized Kupola needs to be put back into the game

- The overall thicknesses and the textures of the IACBMs will need to be tweaked before I re-export them using PartTools 0.20, since the attachment points on some of the Karmony Modules have changed.

- The Warehouse will need a new model with animated bay doors and placeholder innards. I'll leave KASPAR functionality and the rotating rack for later.

[Mihara]

- These new dev parts will break crafts and saves, due to various things I had to do to optimize them, such as tweaking scales and positions in preparation for IVAs.

While you're save-breaking, could you please-please-please consider giving the parts different part names when they suffer a save-breaking update? That makes it much easier to upgrade them.

[sumghai]

While you're save-breaking, could you please-please-please consider giving the parts different part names when they suffer a save-breaking update? That makes it much easier to upgrade them.

I suppose what I could do is to append "_DEV" to the KSP internal part name, and prepend "[DEV]" in the VAB/SPH title, so that you could run both the R0.03.5a and the X0.04-1 parts side by side.

I'm not sure how that would help with upgrading, though, since the positions are likely to be shifted anyway.

[Mihara]

I'm not sure how that would help with upgrading, though, since the positions are likely to be shifted anyway.

When there's two sets of mutually incompatible parts which have the same part names, one can't gradually phase out the old set over time.

[sumghai]

When there's two sets of mutually incompatible parts which have the same part names, one can't gradually phase out the old set over time.

I see what you mean.

But does that mean the new parts will have to retain the "_DEV" bit after their filenames forever, even long after official release? Because that will be really annoying.

[Mihara]

But does that mean the new parts will have to retain the "_DEV" bit after their filenames forever, even long after official release? Because that will be really annoying.

Just give them a different suffix then, instead of "_dev" make them "_optimized" because that's what makes them different?

[sumghai]

Just give them a different suffix then, instead of "_dev" make them "_optimized" because that's what makes them different?

I really don't want to leave any unnecessary suffixes to part names in the long term.

[Gristle]

I'd say just make a clean cut-over. Eventually KSP evolution will force another save file restart on everyone and it won't matter.

[Mihara]

I really don't want to leave any unnecessary suffixes to part names in the long term.

There is such a thing as being too pedantic, considering that in no case a player would be able to see them unless they directly open the config file.

[johnsonwax]

I think having the version number that breaks save compatibility as a suffix would be reasonable.

[Makeone]

Greetings

Has there been any reports of unstable fustek-crafts after the 0.22 update? I lost a decent (but still quite small) station as it just started to wobble without any reason, so came to the conclusion, that those lovely docking ports could be the blame, as some other crafts using them had some serious problems which made me to revert old docking ports, for now, anyway. I like more of fustek-ports, but they do lack one thing, and that's placing them radially (i wonder if that's the right term, i try to mean that no node is required?)

[sumghai]

Has there been any reports of unstable fustek-crafts after the 0.22 update? I lost a decent (but still quite small) station as it just started to wobble without any reason, so came to the conclusion, that those lovely docking ports could be the blame, as some other crafts using them had some serious problems which made me to revert old docking ports, for now, anyway.

I haven't built a proper station since 0.21, but there was one time where a couple of the optimized modules I was testing started wobbling violently when used with with the IACBMs. It never happened again after that, but I suspect phantom forces due to intersecting collider meshes.

I'm already planning to re-export the IACBMs for the R0.04a update anyway, so I'll look into it, but I can't promise anything.

I like more of fustek-ports, but they do lack one thing, and that's placing them radially (i wonder if that's the right term, i try to mean that no node is required?)

A deliberate decision based on my (increasingly convoluted) design philosophy, due to my engineering background.

One thing I don't like about the stock ports is that they could be placed just about anywhere on a fuselage, which in real life would mean randomly cutting into hulls and compromising structural integrity. As such, my IACBMs were design to only be placeable at "sensible" locations that would make structural sense.

[Gristle]

Greetings

Has there been any reports of unstable fustek-crafts after the 0.22 update? I lost a decent (but still quite small) station as it just started to wobble without any reason, so came to the conclusion, that those lovely docking ports could be the blame, as some other crafts using them had some serious problems which made me to revert old docking ports, for now, anyway. I like more of fustek-ports, but they do lack one thing, and that's placing them radially (i wonder if that's the right term, i try to mean that no node is required?)

My large refueling station that was rock solid in .21 is unusable now. As soon as the vessel loads it starts flapping like a wet noodle. All station modules / parts are utilizing SDHI berthing ports except the connection between the fuel bladders which are using Clampotron Sr.

[sumghai]

My large refueling station that was rock solid in .21 is unusable now. As soon as the vessel loads it starts flapping like a wet noodle. All station modules / parts are utilizing SDHI berthing ports except the connection between the fuel bladders which are using Clampotron Sr.

*Sigh*

Like I said, I'm doing what I can.

[Gristle]

*Sigh*

Like I said, I'm doing what I can.

I'm not entirely sure it has anything to do with your parts. I've seen other reports on the forums of weird physics behaviors with conjecture that .22 borked something.

[MOARdV]

I'm not entirely sure it has anything to do with your parts. I've seen other reports on the forums of weird physics behaviors with conjecture that .22 borked something.

I had an ISS JEM module start wobbling maniacally on a station that was otherwise Fustek expansion parts (using IACBMs), and another JEM on a KOSMOS-based space station, but my big-ish Fustek-only station has been stable.

[HeadHunter67]

I really don't want to leave any unnecessary suffixes to part names in the long term.

Then dub these the Mk IV! Would that work?

[BFGfreak]

Honestly I wouldn't worry about save breaking, I mean squad does it and it gives people a chance to fix those things they screwed up on on their previous space stations that have been bugging the hell out of them. Besides this is a sub 1.0 mod so save breaks should be somewhat expected in my opinion, just remember to recreate Gravity before you upgrade and post your pictures of your old stations moments before they plunge to their deaths, preferably with flames and such. (or claim Kethane mining accident or something.)

[DerekL1963]

Just out of curiosity, are those encountering 'flopping' problems upgraded to the latest version of MJ and do you have "Use Stock SAS" toggled off?

[SFJackBauer]

For those with wobble problems, Kerbal Joint Reinforcement might be of utility.

[Gristle]

Just out of curiosity, are those encountering 'flopping' problems upgraded to the latest version of MJ and do you have "Use Stock SAS" toggled off?

I don't use MechJeb.

[sumghai]

Progress Report, 2 November 2013

A reasonably productive last few days indeed.

- All of my existing parts have been optimized now; not much difference other than some visual tweaks and shifts in the top and bottom attachment nodes in the Karmony modules.

- The 1.25m and 2.5m IACBM docking ports have been adjusted to the same thickness, as a consequence of the aforementioned top/bottom node shifts. In layman's terms, a tapered module with two 1.25m IACBMs on both ends should be equal in length to a flat module with two 2.5m IACBMs.

- I've also ultimately decided just to assign the entire station parts pack into the Composites Tech Node, as the in-universe brochure explicitly states that the modules were aluminum structural members covered with composite Whipple shield panels.

- Finally, I've put together a roadmap for the future of these station parts.

With all the annoying little bits and pieces out of the way, I've begun working on a proper model for the Karmony Warehouse. Originally, this was called the Parts Warehouse, and was designed strictly for use with the OrbitalConstruction mod as a storage container for large quantities of RocketParts, using the currently-vapourware KASPAR payload racks for resupply; however, to offer a bit more flexibility, the renamed module will now be designed to accept any KASPAR rack, and not just those used in the OC add-on.

nothke has been busy with Kerbin City, but he stated that other than the width, the dimensions of each rack has been finalized:

Fig 41 - KASPAR payload rack dimensions - note that the width (H=0.65) has not been finalized. (Image courtesy nothke)

After bashing together a quick boilerplate model, I used it to help determine the arrangement of the racks inside the Warehouse module (and by extension, the model of the warehouse itself), bearing in mind that I need to leave enough room for:

- the 80mm hull thickness, as per Fig 17

- the (non-InfernalRobotics) rotating magazine for the KASPAR racks

Fig 42 - (WIP) FusTek Karmony Warehouse Module (revised)

Yeah, I guess that looks about right.

[Scotius]

Yeah, i guess thet looks about awesome Can't wait to try Warehouse on my space station. Sumghai, will you make smaller and lighter version that could be a better fit for interplanetary motherships? For example by cutting Warehouse module to half its lenght?

[SkyHook]

The warehouse module excites me because I might finally be able to construct my bases the way they were meant to be constructed...piece by boring piece!