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

[Docopp]

Are the IACBMs not compatible with stock Clamp-o-trons?

[BFGfreak]

I don't belive they are, I think sumghai configured it so that they are only compatable with eachother, however you could try modifying the CFG files to make them compatable with the stock docking ports, it just won't look too aesthetically pleasing.

[sumghai]

I've started attempts at welding parts together to increase stability and reduce part count (using your modules and stock docking ports as a test). Unfortunately I think trying to create one part with multiple docking ports, while possible, creates too much of a pain in selecting specific docking ports for docking (lets not even go into making sure you have to correct docking port when undocking), being able to name individual docking ports (modules) seems like a good fix. I guess I'm off to see if I'm better at coding than modeling.

Yeah, there's a practical limit to how many PartModules one can put into a monolithic "welded" part before it becomes too unwieldy to use.

Are the IACBMs not compatible with stock Clamp-o-trons?

I don't belive they are, I think sumghai configured it so that they are only compatable with eachother, however you could try modifying the CFG files to make them compatable with the stock docking ports, it just won't look too aesthetically pleasing.

BFGfreak is correct.

The IACBMs are only compatible with themselves (and even then, by size - a 1.25m IACBM can only mate with another 1.25m, while a 2.5m IACBM can only mate with another 2.5m). The meshes themselves visually have different latching ring diameters to the stock ports, so even if they were docked in KSP, it wouldn't look like a secure airtight seal. As such, I added an additional parameter in the CFGs that would deliberately cause docking to fail if an IACBM is used to dock with any other system.

The solution to this incompatibility lies in the Kirs Docking Module, which is essentially a pressurized compartment that can be outfitted with different types of docking ports at both ends (much like the PMAs used between USOS the ROS sections of the ISS). Simply put a Clamp-o-tron on one end, and an IACBM on the other; dock the IACBM end to the rest of your space station, leaving the Clamp-o-tron end free to be used as a berthing location for visiting spacecraft with legacy docking systems.

[BFGfreak]

Now I know I mentioned this earlier, but are there plans to have a Fustek themed docking port that is compatible with the Stock 1.25 port?

[sumghai]

Now I know I mentioned this earlier, but are there plans to have a Fustek themed docking port that is compatible with the Stock 1.25 port?

Probably not. I'm not too fond of the small passage diameter in the stock 1.25m ports.

[Helix935]

i just need to make sure do the new IACBMs rotate when they dock so as to have the right orientation for my obsession for achieving proper symmetry's sake because i know there are docking washers in infernal robotics but they always fill up the screen every time i use a lot of them.....

[sumghai]

i just need to make sure do the new IACBMs rotate when they dock so as to have the right orientation for my obsession for achieving proper symmetry's sake because i know there are docking washers in infernal robotics but they always fill up the screen every time i use a lot of them.....

Only the guidance fins rotate - the docking ports themselves don't.

Rather than docking washers, I use Sarbian's MechJeb2 fork that comes with roll alignment for the Docking Autopilot, which allows you to specify what exact rotational offset you want (in degrees) between the target and your vessel. If you feel the Autopilot is too cheaty, the roll alignment feature is also available in the Smart A.S.S. subsystem.

[Helix935]

ok good to know although i just docked the part while waiting and found the answer although i wonder whenever i undocked it it would not redock with the same IACBM that it had originally docked to.....

this would mean i would have to suffer the fact that it isn't symmetrical now...

[sumghai]

R0.03.5a released - see announcements thread for download link

R0.03.5a          2 September 2013
---------------------------

Fixes
 - Tweaked Karmony End Ring attachment points to accomodate new IACBMs
 - Reworked animation toggling behaviour for IACBM 1.25m, IACBM 2.5m and Kupola
     - The IACBM guidance fin rotary positions and Kupola blast shutters are now also toggleable inside the VAB

[Archer]

Helix, how far did you back off from the port you undocked from? usually you have to back off a few meters before KSP will be willing to dock again.

[Helix935]

ok that explains it

[Gristle]

Only the guidance fins rotate - the docking ports themselves don't.Rather than docking washers, I use Sarbian's MechJeb2 fork that comes with roll alignment for the Docking Autopilot, which allows you to specify what exact rotational offset you want (in degrees) between the target and your vessel. If you feel the Autopilot is too cheaty, the roll alignment feature is also available in the Smart A.S.S. subsystem.

Romfarer's docking cam has a roll indicator that allows fairly precise alignment of docking ports. you just need to be careful during VAB/SPH construction that you don't rotate docking port parts in non 90* increments if you want a precise alignment during orbital assembly.

[tom1499]

Cant wait for the IVA's!

[Blaylock1988]

I don't get the Warehouse Rocketparts volume. It is only 1600 max but even the smallest container from the orbital construction mod can hold 4000....

[Orphican]

I don't get the Warehouse Rocketparts volume. It is only 1600 max but even the smallest container from the orbital construction mod can hold 4000....

For the moment I've gone back to using the large warehouse in Orbital construction. Future stations are probably going to need multiple warehouses but I dont think the amount of rocket parts is a problem yet.

[Blaylock1988]

So I did a little investigative engineering and discovered that even the orbital construction storage volumes are not linear (they don't match up). Using the SpareParts "Medium" Module as my frame of reference, it holds 1,000 rocketparts. The Small Orbital Warehouse is approximately 8 times larger by volume than the Medium module, but it only holds 60,000 when it should be 80,000. The Large Orbital Warehouse is 16 times larger than the medium module and correctly holds 160,000 rocketparts. The SpareParts "Small" Module is 60% size of the Medium module and should therefore hold 6,000 parts, but it incorrectly holds 4,000.

Since the Karmony Parts Warehouse is the same size as the Small Orbital Warehouse, it should hold the same volume CORRECT volume, so I will edit the .cfgs in my install for the karmony warehouses to hold 80,000 parts.

I refuse to attach that ugly orange tank to my station.

[Mihara]

The "correct" volume for rocket parts is a more complicated question, because Orbital Construction mod adopted the resource for compatibility with Extraplanetary Launchpads, which has relatively recently decided to change the density of rocket parts -- previously, they were ridiculously dense, now they're fluffy. Apparently there's still some confusion since.

[Catsceo]

R0.03.5a released - see announcements thread for download link

R0.03.5a          2 September 2013
---------------------------

Fixes
 - Tweaked Karmony End Ring attachment points to accomodate new IACBMs
 - Reworked animation toggling behaviour for IACBM 1.25m, IACBM 2.5m and Kupola
     - The IACBM guidance fin rotary positions and Kupola blast shutters are now also toggleable inside the VAB

Will this break current crafts in orbit using the end nodes?

[Blaylock1988]

Building big things with FusTek!

My orbital construction shipyard. After modifying the warehouse volume

[sumghai]

Stealth patch for R0.03.5a uploaded

CFG change only - this should squash the recurrence of the "breakintTorque" bug.

(Again, my sincerest apologies to everyone for the inconvenience - had a rather minor HDD issue, and while I haven't lost any vital progress in terms of models or textures, the CFGs must've reverted to some old version while I synced some backups.)

[abrr2000]

have you looked at the nautilus pack? it has the exact same styling as the fus tech stuff and looks great when used in unison with it, merging perfectly. however the pack in question has not been updated since 0.18 and is very hard to find so here is a link

http://kerbalspaceprogram.com/0-18-1-mpss-nautilus/

the pack includes an inflatable rotary section for crew (no crew capacity though) and a host of other highly useful stuff) if these 2 packs could be merged it would create the ultimate in space station building kits.

I'd also like to suggest changing many of the components from being command capsules, to being the equivalent of a shinny "hitchhiker storage unit" at the moment kerbals can pilot a ship from there beds or the space toilet. (last I checked kerbals could barely fly from a pilots seat) In addition, tracking the internal view of the dozens of capsules needed to make a space station makes unnecessary hard work for the game engine.

the loss in controllability could be simply replaced by a fustech reaction wheel, and building could still be accomplished by a dedicated construction ship/probe (like I use for construction)

[sumghai]

I'd also like to suggest changing many of the components from being command capsules, to being the equivalent of a shinny "hitchhiker storage unit" at the moment kerbals can pilot a ship from there beds or the space toilet. (last I checked kerbals could barely fly from a pilots seat) In addition, tracking the internal view of the dozens of capsules needed to make a space station makes unnecessary hard work for the game engine. the loss in controllability could be simply replaced by a fustech reaction wheel

Actually, I'm tempted to agree with you.

It's slightly annoying (even for myself) to be launching modules with crew already assigned to them, when in fact they should be launched uncrewed first and then visited by ferrying vessels.

I'm also tempted to strip the modules of MechJeb functionality (with the exception of the Utilities Modules, which are considered the "command centre" for space stations), but keep the reaction wheels already built into the modules.

What does everyone else reckon? Should I remove MechJeb from most modules, keep the reaction wheels, and redefine the crewed compartments as basically glorified versions of Hitchhikers (so that they don't auto-populate with crew at launch)?

building could still be accomplished by a dedicated construction ship/probe (like I use for construction)

I too also use orbital tugs for station construction.

[Milkshakefiend]

I concur with the uncrewed launches and removal of probe command in a majority of modules. I don't really have much of an opinion on keeping MJ as I don't use it, but I don't see why you couldn't have it inbuilt in the modules that do have probe command built in. Keep the reaction wheels though. Between that and the RCS end rings it helps reduce part count a lot.

[Kimberly]

Makes sense to me, sumghai. The modules aren't supposed to be independent, but to form a part of a whole--I say, if you want them to do something they're not designed to do, add on your own part. People can add probe cores if they feel the need. The reaction wheels, though, make sense. I don't use MechJeb myself, but it seems to me that it only needs to be on the actual command module.

[Mihara]

IMHO, the modules should be crew containers with internals but not command modules, i.e. INTERNAL {} but no MODULE {name=ModuleCommand}. An internal, however, any internal at all provided it has enough spots to show all the kerbals in it, is important, because otherwise they don't get portraits and it's easy to miss you even have them in the vessel, which can cost lives. Reaction wheels are also important because otherwise stations would be a real pain to use.

Whether you keep MechJeb in the config files or not makes no particular difference to me though, as it's trivial to patch that one in, but I'd keep it (as well as ModuleCommand) in Karmony Node, as this is one part you're pretty certain to have somewhere in your station, and would ensure that it keeps working.

P.S. Oh, and while we're at it. Kirs and Kuest should probably have GenericSpace1 as their internal at the moment. Sure, it's just an empty box, but it's considerably more appropriate to their actual insides than UniKarmony and would also be less confusing.

Edited September 6, 2013 by Mihara