[1.0.X - Experimental] [On Hold] FusTek Station Parts (WIPs on GitHub)

[futrtrubl]

I installed this and for the core module it shows a Food and Water quantity of "NaN". This in turn makes MechJeb report the craft mass as NaN, and any other stats that depend on the craft mass (e.g. TWR).

I think it's because you have resources where maxQuantity = 0 and it's dividing be zero, but I'm not entirely sure.

Yup maxQuantity = 0 is the culprit. They put it in there so that TAC doesn't add certain resources to some habitable parts, but it isn't a good solution. They need to either put in a very small max amount (emergency supplies if they have to seal themselves in) or use :AFTER[TacLifeSupport] and remove those resource defs.

Edward

Edited June 2, 2014 by futrtrubl

[DPooly]

So, the following is a screen cap of my gamedata folder. As far as I know, I have followed everything correctly. I have all the dependencies. I start KSP, the loading bar loads as normal. However, when it is full, it crashes to desktop.

[wasmic]

So, the following is a screen cap of my gamedata folder. As far as I know, I have followed everything correctly. I have all the dependencies. I start KSP, the loading bar loads as normal. However, when it is full, it crashes to desktop.

http://i62.tinypic.com/2n6x6xw.png

Install BoulderCo active texture management, either aggressive or basic version. Find it here.

[softweir]

Install BoulderCo active texture management, either aggressive or basic version. Find it here.

To explain: crashing to desktop is a symptom of running out of memory, commonly caused by having too many mods with too many textures. If Active Texture Management fixes the problem, then all well and good.

If, however, it doesn't fix the crash then come back for more advice.

Good luck!

[sumghai]

So, the following is a screen cap of my gamedata folder. As far as I know, I have followed everything correctly. I have all the dependencies. I start KSP, the loading bar loads as normal. However, when it is full, it crashes to desktop.

http://i62.tinypic.com/2n6x6xw.png

Install BoulderCo active texture management, either aggressive or basic version. Find it here.

To explain: crashing to desktop is a symptom of running out of memory, commonly caused by having too many mods with too many textures. If Active Texture Management fixes the problem, then all well and good.

If, however, it doesn't fix the crash then come back for more advice.

Good luck!

Active Texture Management is highly recommended if you don't have a lot of RAM and wish to run large numbers of add-ons.

Could you also please post your error logs?

[DPooly]

Install BoulderCo active texture management, either aggressive or basic version. Find it here.

It worked! No crashes, runs nice and smooth again. AND, I have all of the nice and shiny FusTek parts. Yay! You're awesome.

(Not sure how to add multiple quotes)

Sumghai

I have 12GB RAM, 2GB dedicated graphics.

Also, not sure how to attach the error log files.

[OOZ662]

I have 12GB RAM

KSP is a 32bit (apparently large address aware) application and thus tops out at 4gb usable RAM space.

[sumghai]

Glad to hear that things are working again, DPooly! Those logs aren't necessary now.

Also, bear in mind that KSP can only use a maximum of 3.5GB of RAM.

[edemlama]

hello everyone,

is there a texture reduction pack for this mod?

[sumghai]

hello everyone,

is there a texture reduction pack for this mod?

Short answer: No.

Long answer: Many parts already share bits from a common texture set, so there are already significant memory savings.

Depending on your computer's specs and/or number of add-ons you have installed, it is recommended that you get Active Texture Management to automatically reduce textures for all part-based add-ons.

[Starwaster]

(Not sure how to add multiple quotes)

under the person's message you want to quote is dialogue balloon thing with a + next to it.. far right, underneath.

click that for everyone you want to quote.

After you do the last person that way then click 'Reply With Quote'

[softweir]

...

After you do the last person that way then click 'Reply With Quote'

Or, indeed, "Reply to Thread" at the bottom of the page.

[edemlama]

Short answer: No.

Long answer: Many parts already share bits from a common texture set, so there are already significant memory savings.

Depending on your computer's specs and/or number of add-ons you have installed, it is recommended that you get Active Texture Management to automatically reduce textures for all part-based add-ons.

thanks, I'm going to try it out now

[wasmic]

Hey Sumghai, now that SpacePort is down and Fusty's old stuff is gone, how about making a truss section? Possibly with a crew tunnel for use with CLS.

[sumghai]

Hey Sumghai, now that SpacePort is down and Fusty's old stuff is gone, how about making a truss section? Possibly with a crew tunnel for use with CLS.

I've been musing about an ISS-like truss system for some time, consisting of procedural segments for use in the VAB/SPH and docking strut-like segments for EVA construction.

That'll have to wait until V1.0, however.

[Starwaster]

Or, indeed, "Reply to Thread" at the bottom of the page.

Does that work properly with multi-quoting?

[sumghai]

under the person's message you want to quote is dialogue balloon thing with a + next to it.. far right, underneath.

click that for everyone you want to quote.

After you do the last person that way then click 'Reply With Quote'

Or, indeed, "Reply to Thread" at the bottom of the page.

Does that work properly with multi-quoting?

Yep, it definitely does - tried it just now

Also, new dev build coming later this week.

[diomedea]

Sorry in case what is below was already mentioned (though I can't find about it with a fast thread search).

I am testing what I can achieve with Fustek X0.04-3-1 Dev parts. Really beautiful, but I find an issue while surface attaching to them in VAB.

Any of the Karmony modules, when rotated horizontal, show to have a single point from where the collider direction is oriented. That makes other parts to automatically rotate so to follow what appears like a spherical surface when in contact with a module, instead of the cylindrical surface of the module mesh. Those other surface-attachable parts will actually get attached with their center to the module mesh, but oriented in relation to the single-point center of the module, instead of the module center axis. With the warehouse module opened, that behaviour is also found with the internal surface.

The same modules, if kept vertical (as they initially are, not rotated), are absolutely fine, surface attachment works well (parts are oriented in relation to the vertical center axis of the module).

Sorry for any terminology mistake (I may not have right what a collider is, not being a modeler).

Here a short gallery of images that should show the issue.

[softweir]

Does the same thing happen with stock parts, such as the hitchhiker can? If so, then it is probably a KSP bug.

[OOZ662]

I've seen that in a lot of parts mods and have started taking it for granted.

[diomedea]

Does the same thing happen with stock parts, such as the hitchhiker can? If so, then it is probably a KSP bug.

Yes, unfortunately (had to try, I'm not so fond of other parts to try using them in all possible positions). So that may not have a solution until Squad deals with it.

Thank you a lot .

[likke_A_boss]

Sorry in case what is below was already mentioned (though I can't find about it with a fast thread search).

I am testing what I can achieve with Fustek X0.04-3-1 Dev parts. Really beautiful, but I find an issue while surface attaching to them in VAB.

Any of the Karmony modules, when rotated horizontal, show to have a single point from where the collider direction is oriented. That makes other parts to automatically rotate so to follow what appears like a spherical surface when in contact with a module, instead of the cylindrical surface of the module mesh. Those other surface-attachable parts will actually get attached with their center to the module mesh, but oriented in relation to the single-point center of the module, instead of the module center axis. With the warehouse module opened, that behaviour is also found with the internal surface.

The same modules, if kept vertical (as they initially are, not rotated), are absolutely fine, surface attachment works well (parts are oriented in relation to the vertical center axis of the module).

Sorry for any terminology mistake (I may not have right what a collider is, not being a modeler).

Here a short gallery of images that should show the issue.

I have had this issue, too, but i have fixed it my turning the part snapping (?) off, back to the sphere. Then it works.

[diomedea]

I have had this issue, too, but i have fixed it my turning the part snapping (?) off, back to the sphere. Then it works.

Yes, seems to work for me too. Thanks for your suggestion .

[sumghai]

X0.04-4 DEV BUILD released - see first post for download link

X0.04-4 DEV BUILD  5 June 2014
---------------------------
Features:
 - New Parts
    - Karmony Payload Bay Module
    - Karmony Payload Bay Module Adapter
 - The Payload Bays are genericized variants of the Warehouse module  that will be designed without the rotating payload rack magazine
 - Deadly Re-entry Continued support added
    - All FusTek parts will burn up during atmospheric re-entry (specifically, above 800°C)
    - If you're planning on building surface bases on Duna and Laythe, be sure to install heat shields properly
    - A Module Manager config, FusTek_MMPatch_DeadlyReentry.cfg, can be  found under GameData\FusTek\Station Parts\Parts\MM_configs, and is used  to define maximum heat tolerances for all FusTek parts
 - TAC Life Support integration finalized
    - Each module will have varying amounts of crew provision / waste  storage tanks and resource processing capabilities, depending on their  intended purpose
    - A Module Manager config,  FusTek_MMPatch_TACLifeSupport_ModularFuelTanks.cfg, can be found under  GameData\FusTek\Station Parts\Parts\MM_configs, and is used to define  life support resource quantities for each FusTek part
 - The FusTek Resupply Module is now pre-configured to carry both life  support crew provisions and various types of spacecraft fuel for  resupplying space stations / planetary outposts
    - Crew provision quantities can be altered using the stock KSP tweakables system
    - Varying combinations of LiquidFuel/Oxidizer/Monopropellant/Xenon  can be filled using Modular Fuel Tanks, up to a maximum total mass of  800 kg

Changes:
 - Crew habitable modules now have unique IVAs
    - At present, they are only used to test layouts and crew seating positions
 - Karmony Utilities Modules can now hold up to 500 units of ElectricCharge
 - Some Karmony module viewports have been repositioned to match up with the WIP internals
 - Kirs Docking Module hatches have been resized to match up with the WIP internals
 - Inner bay textures for Karmony Warehouse and Payload Modules finalized

Fixes:
 - Kuest / Kuest Legacy Airlocks will now store science reports acquired from EVA
 - Alternative texture switching now supports multiple objects with the same name on the same part
    - This requires the experimental v6.4 pre-release of the Firespitter plugin

Issues:
 - IVAs are still a work in progress
    - Models and textures are placeholders
    - RasterPropMonitors are not yet implemented
 - KSO Phase II Alternative Textures have not been updated to coincide with changes / new parts
    - That's Sippyfrog's responsibility, not mine 
 - Warehouse has incomplete functionality
    - Work will on this will continue in R0.05a

---

Sorry in case what is below was already mentioned (though I can't find about it with a fast thread search).

I am testing what I can achieve with Fustek X0.04-3-1 Dev parts. Really beautiful, but I find an issue while surface attaching to them in VAB.

Any of the Karmony modules, when rotated horizontal, show to have a single point from where the collider direction is oriented. That makes other parts to automatically rotate so to follow what appears like a spherical surface when in contact with a module, instead of the cylindrical surface of the module mesh. Those other surface-attachable parts will actually get attached with their center to the module mesh, but oriented in relation to the single-point center of the module, instead of the module center axis. With the warehouse module opened, that behaviour is also found with the internal surface.

The same modules, if kept vertical (as they initially are, not rotated), are absolutely fine, surface attachment works well (parts are oriented in relation to the vertical center axis of the module).

Sorry for any terminology mistake (I may not have right what a collider is, not being a modeler).

Here a short gallery of images that should show the issue.

Does the same thing happen with stock parts, such as the hitchhiker can? If so, then it is probably a KSP bug.

I've seen that in a lot of parts mods and have started taking it for granted.

Yes, unfortunately (had to try, I'm not so fond of other parts to try using them in all possible positions). So that may not have a solution until Squad deals with it.

Thank you a lot .

I have had this issue, too, but i have fixed it my turning the part snapping (?) off, back to the sphere. Then it works.

Yes, seems to work for me too. Thanks for your suggestion .

I've actually experienced this issue not only with the very first version of FusTek (R0.01a), but with all KSP parts in general.

I suspect that this is because part snapping is partially dependent on the transform of the root part; the reason you are able to get proper surface attachment when modules are merely vertical is because most KSP parts have their default part transforms pointing upwards.

As there are times I still wish to use part snapping in such situations, a solution would be to use SelectRoot to temporarily change your root part so that part snapping for surface attached parts on horiztonally-oriented modules work properly, then switch back to the original root part as required.

[diomedea]

As there are times I still wish to use part snapping in such situations, a solution would be to use SelectRoot to temporarily change your root part so that part snapping for surface attached parts on horiztonally-oriented modules work properly, then switch back to the original root part as required.

Another excellent suggestion. Thank you .

BTW, very happy to find a new version. Impressive work!