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

[Starwaster]

Yes there is, but not one that works in RSS (Real Solar System) and RO (Realism Overhaul).

yeah but that doesnt mean you need a whole new buran. you just need the existing ones engines and fuel tanks edited.

[Deathsoul097]

And set up to work with FAR, and a multitude of other mods, which I know how to do, but don't have the time.

[XanderTek]

Sumghai, would it be possible to have the warehouse doors open by default so that items can be mounted inside in the VAB? I know it's mainly a stand in until FLEXracks show up, but I think with that small change the part could be quite useful as-is.

Edit: Well, you're clearly a few steps ahead on this The cfg files already support this. Simply setting startDeployed = true causes the doors to be open in the VAB.

Edited December 9, 2013 by XanderTek

[sumghai]

(Almost No) Progress Report, 15 December 2013

Now that RealChutes and SDHI are pretty much done, I can finally get back to FusTek.

After much difficulty, I temporarily uninstalled Kerbal Join Reinforcement and managed to reproduce the issue regarding the wobbling docking ports. As far as I'm concerned, it's definitely the hatch/docking mode toggle - I suspect this is because the associated collider is part of an animation, and so KSP has to store/recall its animated state whenever a vessel is loaded. I may have a solution involving extra colliders and intrinsic part clipping, but as usual I make no promises it will work for everyone.

On the subject of IVAs, I haven't progressed much beyond that Kirs Docking Module prototype due to the following reasons:

- I'm trying to put together a library of common FusTek props; the could range from small items (e.g. drawer labels, fire extinguishers) to reusable structural features (e.g. hatches, frames). I'll need to sit down, sketch some concept images and make a list of which elements I can reuse and which I'll have to permanently model as part of the actual IVA base mesh.

- I do intend on making use of Mihara's RasterPropMonitor for practically all displays and indicators. Again, I'll need more time to sit down and decide which modules will get displays as well as what functions / features will be available.

- In relation to the previous point, I'm not sure how I'd want to do the docking camera. Personally, I'm of the opinion that since any given FusTek'd station would have any number of IACBMs, it becomes impractical to set up RPM displays for every single one of them. Instead, I'll limit camera transforms to the "Visiting Spacecraft End" of the Kirs Docking Module, since I imagine where most of the traffic to/from any station would be.

So yeah, I'm back, but there's not much to show for it.

[czokletmuss]

Would you be giving FusTek modules the funcionality of the new vanilla part (Lab) which enables to process science into more science?

[sumghai]

Would you be giving FusTek modules the funcionality of the new vanilla part (Lab) which enables to process science into more science?

Yes, the Karmony Science Module(s) will be equivalent to the upcoming vanilla Science Lab.

[Starwaster]

I'm sure limiting cameras to the airlock is fine. Perhaps way way down the line they could be made an optional extra with .23 tweakables

[sumghai]

Minor hotfix to X0.04-1 DEV BUILD released - refer to the blog post for download link

Removed Hatch Mode toggle feature and tweaked colliders for IACBM docking ports. Kerbals will now be able to EVA through them, except when the hatch is obstructed by another docking port.

Testing on my own setup (without Kerbal Joint Reinforcement) suggests some improvement to the wobbling docking port issue, although there's nothing I can do for those who build noodly space stations.

---

I'll probably need to completely redo the common texture atlas for the parts, to cater for the non-repeated alternative textures nothke* was harping about recently, at the cost of greatly increased texture filesize and further delays to R0.04a.

[Read have Read]

I tried the Dev Build today:

• I immediately noticed while putting parts together in the VAB that the Kupola incurs a performance hit of 7-10 frames per second.
  
• From 45 FPS: adding one Kupola will drop performance down to 35 fps, the second Kupola down to 25 fps, and the third down to 20, the forth goes to 15, the sixth down to 10.
  
• Removing the stack of 6 Kupolas puts my frame rate back to 45fps.
  
• A tree made of 3 stacked Karmony Nodes with IACBM's on all 4 ports and a module attached to each gets a respectable 30 fps, doubling that tree have 6 Node with 8 IACBMs and 4 Moduels each (72 parts) gets 20 fps.
  
• Removing the IACBM's and adding another stack of 3 nodes with 4 modules each maintains an FPS rate of 28. Adding 6 squad Cupola command pods also results in 30 fps and surprisingly the frame rate hit does not add up, staying at 30 whether there is 4 or 16 cupola pods.
  
• Quad symmetry for adapter modules refuses to attach, like if it thinks it is clipping, but it attaches happily in 4x symmetry with squad Clampotrons. Does not happen with Flat ended Modules.
  
• Starting at 50 fps with 4 clampotrons, to 38fps for two nodes; 42 fps for 4 nodes, and still 38 fps for 8 nodes with 4 pairs of clampotrons and modules. (96 Parts)
  
• Replacing the 32 modules on the clampotrons and nodes with 2 hitchhikers (64 hitchhikers) each resulted in 52 frames per second. Replacing clampotrons with IACBMs on 8 nodes resulted in a frame rate of 20-12 fps.
  

Additionally to note, the Clampotrons are all equipped with a docking camera module for RasterProp while the IACBMs are not

A sample of the testing rig

Good news on the bendy ports! IACBMs had less flex than stock clampotrons when giant 2.5 metre, 40 ton fuel tanks are connected to it. When sent to the launch pad, the Stock ports flexed so much they ripped off and exploded, leaving the IACBM below them as survivors. They also displayed less flex with 20 ton, 2.5 metre tanks.

Edited December 22, 2013 by Read have Read

[Z3R0_0NL1N3]

Hey, since 0.23 allows tweakables in the VAB, is there a way to allow tweakables for the IACBMs? (For instance, toggling which mode to put them in.)

[Deathsoul097]

Compatible with 0.23?

[Helix935]

yes-ish i mean you can use 4.1 because it is already on the tech tree last i checked in composites

[Starwaster]

Good news on the bendy ports! IACBMs had less flex than stock clampotrons when giant 2.5 metre, 40 ton fuel tanks are connected to it. When sent to the launch pad, the Stock ports flexed so much they ripped off and exploded, leaving the IACBM below them as survivors. They also displayed less flex with 20 ton, 2.5 metre tanks.

http://i.imgur.com/sqNZMhg.png

The stock port configuration files are missing entries for breakingTorque & breakingForce, as are many other stock parts. If you've ever had a ship/station spontaneously come apart or have pieces just fall off when it was under no apparent stress (floating in orbit) that's why.

Starwaster's obligatory breakingForce fix follows: (requires ModuleManager 1.5.x)

@PART[*]:HAS[~breakingForce[]]
{
	breakingForce = 200
}
@PART[*]:HAS[~breakingTorque[]]
{
	breakingTorque = 200
}

[cy-one]

Is there a chance you (sumghai, of course) would be willing to share the font you used for the writings on the modules?

I'm currently setting up a fresh .23 installation and would like to fool around with some industrial stations (kethane, orbital construction, etc). I'd like to mod some new modules, using your parts... But of course, they should be labelled correctly

You see where I'm going, I think. Would be nice if the labels would fit in style.

[Kanddak]

Is there a chance you (sumghai, of course) would be willing to share the font you used for the writings on the modules?

Sumghai says:

Microgramma - an oldie but a goodie.

[Dreadp1r4te]

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.

Am I missing something here? Can the new docking ports in FusTek dock with 1.25m stock ports? If not, I realize I could just put 1.25m IACBMs on the nose of my spacecraft to dock with my stations, even though this looks a bit odd, but that's a big no go for my spaceplanes; they all use B9s animated dock, which is compatible with the stock 1.25m ports.

[Starwaster]

Am I missing something here? Can the new docking ports in FusTek dock with 1.25m stock ports? If not, I realize I could just put 1.25m IACBMs on the nose of my spacecraft to dock with my stations, even though this looks a bit odd, but that's a big no go for my spaceplanes; they all use B9s animated dock, which is compatible with the stock 1.25m ports.

No they do not dock with stock parts. There is a way to force them to by editing the cfg file but it would not look pretty.

At all.

[Railgunner2160]

True, but you could always build an adapter!! Take a probe core and slap the normal port on one side and the IACBM on the other...

[sumghai]

Progress Report, 9 January 2014

Been quite busy with IRL stuff, but occasionally I find time to look into FusTek - at least, in my personal dev build.

- The Karmony Science Modules now actually work like the stock science labs, for analyzing/resetting experiments. In exchange, I removed their reaction wheels.

- Tweakables for the IACBM fin animations, Kupola window blast shutters and Warehouse bay doors are proving to be a bother. At the moment, I'm using the Firespitter plugin (which already supports tweakables), but I've been having trouble porting the new Firespitter source code into my lightweight, recompiled authorized version (FusTek_Sumghai.DLL).

- On a related note, I also need to figure out how to add the VAB/SPH texture swapping system from Firespitter to my plugin.

- Just started revising the common texture atlas to allow for nothke-style alternate textures for the modules, at the cost greatly-increased image file sizes.

Do you guys think I should just make the Firespitter.DLL a dependency rather than waste time recompiling my own version?

[Deathsoul097]

Yeah, I think it would be better and easier, and you can distribute it as part of this mod as well. (With Snjo's permission, of course. Thats what Bac9 does.)

[Dreadp1r4te]

Good idea, yeah. Would also make compatibility updates slightly easier, if compatibility with newer versions is dependent on Firespitter being updated. Case in point, B9 doesn't technically support .23, but since both Exsurgent and Firespitter have been updated to .23, just updated the two plugins fixes the incompatibility. Granted this wouldn't be the case with every update, but in this situation it was convenient because Bac9 is fairly busy if I recall correctly.

[TheDude]

Greetings,

I would make it a dependency. No sense reinventing the wheel and it's already distributed with other mods (Spherical Tanks) so most people may already have it.

Regarding the Kupola - I found an interesting FSP issue with it while building a space station. I had a station with 12 habitat modules that I wanted to finish off with Kupolas. 12 kupolas later the game was just crawling along at about 8 FPS while I'm still in the SPH. I never launched because if I'm getting 8 FPS in the SPH then it'll be a slide show in space.

Anyway, as I removed the kupolas one-by-one the FPS would increment upward until it was back to normal. (60+ FPS.) It was a bit of a disappointment as I really like that module but the FPS hit was just brutal.

If it helps - I went into the config file for that part and removed everything except the actual kupola model. The modules, bottom ring, hatches... everything. Unfortunately, it didn't help the problem.

Best regards,

The Dude.

[DerekL1963]

Do you guys think I should just make the Firespitter.DLL a dependency rather than waste time recompiling my own version?

Yes, regardless of the number of characters I use.

[Captain Sierra]

Do you guys think I should just make the Firespitter.DLL a dependency rather than waste time recompiling my own version?

I'd rather ya didn't. I already have 7 different copies of firespitter.dll in my ksp_win folder. The last thing I need is more. I have attributed at least one bug weirdness to running multiples of the same plugin.

I'm quite content with you just recompiling what of it you need into your own plugin. It's less stuff that can go wrong when I install my second favorite parts pack.

[NoMrBond]

I'd rather ya didn't. I already have 7 different copies of firespitter.dll in my ksp_win folder. The last thing I need is more. I have attributed at least one bug weirdness to running multiples of the same plugin.

I'm quite content with you just recompiling what of it you need into your own plugin. It's less stuff that can go wrong when I install my second favorite parts pack.

... just pull all the redundant multiple copies, you only need one.