[24.2] Karbonite Ongoing Dev and Discussion

[gh7531]

@RoverDude

First I want to thank you for this awsome mod. Realy nice work

Second due to the fact that I don't found any MM-files for RealFuels/ModularFuelSystem and Karbonite I'm currently working on a integration in RealFuels (http://forum.kerbalspaceprogram.com/threads/64118) and ModularFuelSystem (http://forum.kerbalspaceprogram.com/threads/64117) for my self. If you (or any one else ) are intersted I will give you the files of course. Let me know if you are interested I'll create a thread then.

[maxrsp]

I have a request that may well be out of scope for this project but I'll make the case anyway...

Consider a dynamic fuel line that can be deployed to connect one ship to another for the purpose of Karbonite or other fuel transfer. I see this functioning more like the now defunct Quantum Fuel Transfer mod than KAS fuel lines, but anything that works would be fine by me. And while I realize KAS can create dynamic fuel lines, there are several reasons why I don't use KAS and would love to see a more focused alternative (KAS has a lot of additional functionality which I wouldn't use).

Just think of that orange pipe dynamically connecting your Mun surface refinery to refuel your multi-mission landers. This would also make shuttling Karbonite into orbit more efficient because you wont have to lift your whole drilling assembly every time or develop a complex two-part dockable drill and shuttle.

One part, one function, fuel system complete

Edited August 4, 2014 by maxrsp

[RoverDude]

I have a request that may well be out of scope for this project but I'll make the case anyway...

Consider a dynamic fuel line that can be deployed to connect one ship to another for the purpose of Karbonite or other fuel transfer. I see this functioning more like the now defunct Quantum Fuel Transfer mod than KAS fuel lines, but anything that works would be fine by me. And while I realize KAS can create dynamic fuel lines, there are several reasons why I don't use KAS and would love to see a more focused alternative (KAS has a lot of additional functionality which I wouldn't use).

Just think of that orange pipe dynamically connecting your Mun surface refinery to refuel your multi-mission landers. This would also make shuttling Karbonite into orbit more efficient because you wont have to lift your whole drilling assembly every time or develop a complex two-part dockable drill and shuttle.

One part, one function, fuel system complete

What I would do is just implement a small, radially attached, expandable ARM-Claw that could be used for fuel transfer. No muss no fuss.

[Justin Kerbice]

Does the KA stack engine have an issue ? It need ScoopedAir like the 2 others but... don't have any dedicated intake and no parts provide ScoopedAir like intakeair for stock air intakes.

Providing some examples may be a good idea.

(dev release 0.0.12)

[Nori]

Been playing around with Karbonite and I really like it. Great job on this mod. It is amazing how quickly you got this put together and as fully featured as it is.

Got a question and some feedback. Is adding another resource conversion as simple as adding it to the converter config? So if I wanted to convert karbonite to hydrogen (from near future mod) I could basically just copy the config for liquid fuel and put in the resource name for hydrogen?

For the feedback. I feel like Karbonite masses too much. From what I can tell it masses 2.5x more than liquid fuel. I understand and appreciate there being a conversion penalty and a urgency to converting Karbonite, but this seems to make hauling resources from say the Mun to a orbiting fuel station rather un-lucrative.

I tested it out just to make sure I wasn't crazy; put on the 1450 Karbonite tank and a empty fuel tank. It weighed about 25,000. After converting all the Karbonite to fuel/oxidizer it weighed in around 14,000. Just thought that was a little much.

I just can't imagine using a Karbonite engines when Karbonite weighs so much. My ship would be so heavy!

Just some thoughts. Maybe lowering it would be too much. Not sure.

[RoverDude]

Been playing around with Karbonite and I really like it. Great job on this mod. It is amazing how quickly you got this put together and as fully featured as it is.

Got a question and some feedback. Is adding another resource conversion as simple as adding it to the converter config? So if I wanted to convert karbonite to hydrogen (from near future mod) I could basically just copy the config for liquid fuel and put in the resource name for hydrogen?

For the feedback. I feel like Karbonite masses too much. From what I can tell it masses 2.5x more than liquid fuel. I understand and appreciate there being a conversion penalty and a urgency to converting Karbonite, but this seems to make hauling resources from say the Mun to a orbiting fuel station rather un-lucrative.

I tested it out just to make sure I wasn't crazy; put on the 1450 Karbonite tank and a empty fuel tank. It weighed about 25,000. After converting all the Karbonite to fuel/oxidizer it weighed in around 14,000. Just thought that was a little much.

I just can't imagine using a Karbonite engines when Karbonite weighs so much. My ship would be so heavy!

Just some thoughts. Maybe lowering it would be too much. Not sure.

Yep, just a config tweak. btw - the weight is part of what balances Karbonite engines - it's just not effective to haul around, at least not without the heavy thrust of a Karbonite engine. I guess my counterpoint would be that I find the idea that folks would mine a raw material, then launch a ship to orbit to process it, not the most efficient thing in the world. It makes sense in Kethane because there's no real difference, and better to leave it in a malleable form (i.e. why have a surface rig and all of it's headaches? Just deal with it in orbit). On the flipside, ORS removes the pain of finding a good spot or establishing a permanent base, so it needed a counterbalance otherwise Karbonite is a bit too much of an 'i win' resource.

Hope that makes sense?

[Fiontar]

I found the fix for my problem. I don't know why this works this way, but hopefully it will be useful for RoverDude.

Reminder of my problem:

KSP 24.2 64-bit, OpenGL (Windows 8.1 64)

Saved game with Orbital Kolinization Station, numerous OKS segments.

With Karbonite Installed, loading that save = Crash when trying to load the station.

If any bit of Karbonite was installed, crash.

Solution:

Place Karbonite Folder in GameData Root, (rather than in UmbraSpaceIndustries).

Place karbonite.dll and USITools.dll in GameData Root, (rather than in UmbraSpaceIndustries).

Game loads fine, station loads fine, KSP64/OpenGL. Station also loads faster in KSP32 OGL.

I was also able to research and place Karbonite parts, so everything seems to be working.

I'm not a programmer, but I'm guessing there is a very good reason as to why the mod and it's components only work when placed in these locations and load quicker, as a result, in the client/render combos where they didn't cause a crash previously.

BTW, it's not just that they needed to be out of the USI folder, if they are anywhere but as described above, issues ensue.

RoverDude, does this make sense to you and is it something you can fix?

I'm guessing that KSP64 running OpenGL is particularly finicky about pathing of mod assets compiled by Unity. Can you confirm this and (hopefully) ensure that the pathing is friendly for 64bit OpenGL in future releases? Or, absent that, test pathing of future releases and provide alternate install directions for those using 64bit OpenGL?

I spent several hours troubleshooting the issue, I'm just curious why the pathing is wrong and if it's something you can easily fix.

TIA

[BigFatStupidHead]

For the feedback. I feel like Karbonite masses too much. From what I can tell it masses 2.5x more than liquid fuel. I understand and appreciate there being a conversion penalty and a urgency to converting Karbonite, but this seems to make hauling resources from say the Mun to a orbiting fuel station rather un-lucrative.

Personally, I like to think of Karbonite as something like crude oil. Not nice, liquidly crude; but nasty oil sand crude, mixed with a ton of useless slag.

[Nori]

Yep, just a config tweak. btw - the weight is part of what balances Karbonite engines - it's just not effective to haul around, at least not without the heavy thrust of a Karbonite engine. I guess my counterpoint would be that I find the idea that folks would mine a raw material, then launch a ship to orbit to process it, not the most efficient thing in the world. It makes sense in Kethane because there's no real difference, and better to leave it in a malleable form (i.e. why have a surface rig and all of it's headaches? Just deal with it in orbit). On the flipside, ORS removes the pain of finding a good spot or establishing a permanent base, so it needed a counterbalance otherwise Karbonite is a bit too much of an 'i win' resource.

Hope that makes sense?

Makes sense. I do really like not having to land at a specific spot to get a bit of a top off. With life support it becomes a balancing act between how much time can I waste getting more fuel.

It just feels so wrong to haul a empty tank of Karbonite into space.

[RoverDude]

RoverDude, does this make sense to you and is it something you can fix?

I'm guessing that KSP64 running OpenGL is particularly finicky about pathing of mod assets compiled by Unity. Can you confirm this and (hopefully) ensure that the pathing is friendly for 64bit OpenGL in future releases? Or, absent that, test pathing of future releases and provide alternate install directions for those using 64bit OpenGL?

I spent several hours troubleshooting the issue, I'm just curious why the pathing is wrong and if it's something you can easily fix.

TIA

To be honest, that makes no sense - a graphics driver should not care at all about the pathing. Are you hitting a 255 character path limitation? That's a windows thing. So I really can't see changing the pathing for Karbonite and all of my mods, as there are a lot of shared components (hence the USI folder), and it would absolutely break some of them because of how KSP loads DLLs.

A bigger question would be whether or not there are other folks in the thread using OpenGL and 64 bit who are NOT having the issue. i.e. it could be something completely orthagonal, since by moving the files you changed the load order (trust me, this matters - there is a VERY good reason USI starts with a 'U' - I had to ditch Green Mesa Industries when I started modding due to DLL loading issues).

[RoverDude]

Makes sense. I do really like not having to land at a specific spot to get a bit of a top off. With life support it becomes a balancing act between how much time can I waste getting more fuel.

It just feels so wrong to haul a empty tank of Karbonite into space.

What would be nice would be super-lightweight inflatable fuel tanks.

Damn... I think I just talked myself into a new mod...

[nli2work]

What would be nice would be super-lightweight inflatable fuel tanks.

Damn... I think I just talked myself into a new mod...

Why not just convert porkjet's hab modules into fuel tanks? they can double as 0-g swimming pools.

[drtedastro]

Why not just convert porkjet's hab modules into fuel tanks? they can double as 0-g swimming pools.

And, they already have a supply of duct tape included.....

[pellinor]

Do you need large Karbonite tanks at all? To me it sounds like the most efficient solution is a very small tank that mainly acts as a fuel line between a drill and a converter.

edit: ah, forgot about the Karbonite engines, now this makes much more sense.

Edited August 4, 2014 by pellinor

[RoverDude]

Why not just convert porkjet's hab modules into fuel tanks? they can double as 0-g swimming pools.

Non-permissive license unfortunately (no derivatives), unless that changed recently. I'm thinking radially attached ones that dynamically expand as fuel is added

[Robotengineer]

Here is a first pass on the air scoop.

I'm trying to think of the best way to join the two side intakes with the center one, any ideas?

[vasco]

any chance of someone making a USI icon for partcatalog?

I have made icons for Karbonite:

[Nertea]

Just a heads up - working on Jumbo-64 and Rockomax x32 sized 2.5m tanks as well to keep the styles common.

[Fiontar]

To be honest, that makes no sense - a graphics driver should not care at all about the pathing. Are you hitting a 255 character path limitation? That's a windows thing. So I really can't see changing the pathing for Karbonite and all of my mods, as there are a lot of shared components (hence the USI folder), and it would absolutely break some of them because of how KSP loads DLLs.

A bigger question would be whether or not there are other folks in the thread using OpenGL and 64 bit who are NOT having the issue. i.e. it could be something completely orthagonal, since by moving the files you changed the load order (trust me, this matters - there is a VERY good reason USI starts with a 'U' - I had to ditch Green Mesa Industries when I started modding due to DLL loading issues).

I'll back up my GameData and see if I can replicate the issue with a minimal set of mods.

What I was wondering was if, while developing Karbonite, you did so from a clean GameData folder and rather than nesting Karbonite inside of the USI folder, it was in the root Gamedata folder at the time you compiled the mod in Unity? Or, that the pathing in settings in Unity were off and for some reason OpenGL is less forgiving? The station load crashed in KSP64 OpenGL, with the files in the location where the install places them, but the load times were long when loading the station in KSP32 OpenGL, even though it didn't crash. Moving Karbonite and the DLLs to the GameData root solved both issues.

As to the 255 character pathing limit, my KSP is a steam installation, so it's deeper from the C: root directory than an non-Steam install, but still only about 110 characters to the deepest directory with in Karbonite.

I had earlier builds of Karbonite installed with out issue, which I why I wonder if something changed in your development process when compiling the mod?

Edited August 4, 2014 by Fiontar

[Nori]

Do you need large Karbonite tanks at all? To me it sounds like the most efficient solution is a very small tank that mainly acts as a fuel line between a drill and a converter.

edit: ah, forgot about the Karbonite engines, now this makes much more sense.

If you use the karbonite engines then you probably want em. But for a exploration/landing ship, just get a 100-200 tank and convert on the go.

I was thinking I might try adding a tiny tank into the converter just to reduce the parts needed.

[nli2work]

Here is a first pass on the air scoop.

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

I'm trying to think of the best way to join the two side intakes with the center one, any ideas?

I think just the central one would be fine. player can radial attach as many as they want.

[maxrsp]

What I would do is just implement a small, radially attached, expandable ARM-Claw that could be used for fuel transfer. No muss no fuss.

That works of course, but not very elegant... so it doesn't match with my beautiful Karbonite shuttles

[Fiontar]

RoverDude,

It might be as simple as the mods evolution breaking the save. Why it would break on 64bit OpenGL, become sluggish but still load on 32Bit OpenGL, while apparently nor being broken at all on Direct3D, I have no idea. I'll reinstall your latest versions in their default locations and start a new game on OpenGL 64-bit KSP. Hopefully future updates won't be save game breaking for me.

[RoverDude]

Do you need large Karbonite tanks at all? To me it sounds like the most efficient solution is a very small tank that mainly acts as a fuel line between a drill and a converter.

edit: ah, forgot about the Karbonite engines, now this makes much more sense.

There's already a tiny VTS sized tank and a larger radial one

Here is a first pass on the air scoop.

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

I'm trying to think of the best way to join the two side intakes with the center one, any ideas?

I think just the central one would be fine. player can radial attach as many as they want.

Looking good I can go either way - either a wide scoop with three vents (but make it appear as a piece with the three vents) or a rounder scoop with the one vent. Add in some side piping or hoses for greebling, and since I see a supercharger bit, add an animated fan that spins, that would be extremely sweet!

Just a heads up - working on Jumbo-64 and Rockomax x32 sized 2.5m tanks as well to keep the styles common.

Awesome, I will deprecate TweakScale once those come in

I'll back up my GameData and see if I can replicate the issue with a minimal set of mods.

What I was wondering was if, while developing Karbonite, you did so from a clean GameData folder and rather than nesting Karbonite inside of the USI folder, it was in the root Gamedata folder at the time you compiled the mod in Unity? Or, that the pathing in settings in Unity were off and for some reason OpenGL is less forgiving? The station load crashed in KSP64 OpenGL, with the files in the location where the install places them, but the load times were long when loading the station in KSP32 OpenGL, even though it didn't crash. Moving Karbonite and the DLLs to the GameData root solved both issues.

As to the 255 character pathing limit, my KSP is a steam installation, so it's deeper from the C: root directory than an non-Steam install, but still only about 110 characters to the deepest directory with in Karbonite.

I had earlier builds of Karbonite installed with out issue, which I why I wonder if something changed in your development process when compiling the mod?

Unity paths have no relation to where the mu ends up. I develop with all of my stuff in exactly the same place you see there. I'm sorry, but you have something else weird going on and I'm at a loss. To confirm: you have used a 100% clean KSP install, with just Squad and NASAMission in GameData, and have extracted the entire contents of the Karbonite zip, correct? No other mods?

[RoverDude]

RoverDude,

It might be as simple as the mods evolution breaking the save. Why it would break on 64bit OpenGL, become sluggish but still load on 32Bit OpenGL, while apparently nor being broken at all on Direct3D, I have no idea. I'll reinstall your latest versions in their default locations and start a new game on OpenGL 64-bit KSP. Hopefully future updates won't be save game breaking for me.

Every indication points to something being installed that conflicted with a DLL, not a DLL issue (otherwise it would not work no matter where you moved it). Which makes sense given how KSP works. This is not a Unity issue, it's flat out a KSP and DLL conflict issue - I just don't know what that issue is.