[24.2] Karbonite Ongoing Dev and Discussion

[nli2work]

2. It would be REALLY nice if the KAE-150S stack jet engine had an attachment node on the tailpipe so you could stack it on top of other rocket parts (say a transfer stage). That way you could use just a single engine on a small plane.

Officially I'll keep it without bottom stack node. like other stock turbojets. Nothing prevents you from editing your config to add stack node however. just remember to change the attachment rules to allowStack.

4. Attaching the radial KAE-75Q and KAE-150R engines with symmetry on results in assymetrical flameout, even though each has its own integral intake. Putting them on 1 at a time solves the assymetrical flameout issue but can result in assymetrical placement and thus thrust, especially if hanging them under/over wings. Is there a way to fix this?

this is normal to multiple air breathing engines, just part of the challenge in flying multi-engine aircraft.

5. Despite their slightly different stats, I don't see any significant performance difference between the jet and turboprop engines. All of them will get you to 1100m/s at 30km on Kerbin (using NEAR). I don't mind this for the jets (I'm trying to make SSTOs after all) but this seems a bit extreme for a turboprop (although it IS cool in a Kerbal way ).

the blades are deceiving, they are Ultra High Bypass turbofans, or Unducted Turbofans. not the same as Turboprops. You can think of the one with visible blades as the other radial turbofan without the ducting. While the stack jet engine is a Turbojet. fluff aside; in terms of performance in game, KAE75Q and KAE-150R have similar thrust; KAE-150R has higher ISP and slightly heavier; while KAE-150S has worst ISP out of the 3, but much higher thrust.

Edited August 16, 2014 by nli2work

[pellinor]

4. Attaching the radial KAE-75Q and KAE-150R engines with symmetry on results in assymetrical flameout, even though each has its own integral intake. Putting them on 1 at a time solves the assymetrical flameout issue but can result in assymetrical placement and thus thrust, especially if hanging them under/over wings. Is there a way to fix this?

this is normal to multiple air breathing engines, just part of the challenge in flying multi-engine aircraft.

If symmetry causes asymmetric behavior this is hopefully a bug in the game and not meant as a nice game challenge. If symmetry really is the cause there is a 'break symmetry' mod that might help. I've also read that flameout starts at either the first or the last engine you put on the craft, so if that is centered you can put others any way you want.

Edited August 16, 2014 by pellinor

[marce]

So discussion time

First... you guys are getting on-rails converters for the particle collector and the drills in the next release. Atmo converters don't make a lot of sense since these don't operate on rails, and rely on speed and atmo pressure.

Second. A common area of concern is the fact that we have infinite resources, with your only variance being efficiency. Efficiency was annoying without rails, and becomes irrelevant with rails (other than extreme cases).

One could argue this could be a concern for manned bases (life support limitations), but as of now, I could just drop a probe core and a drill, add a REALLY big tank, and just let it ride on the rails till my Duna team gets there a year or two later, all with zero penalty for hitting more or less efficient hotspots.

Other mods have solved this through resource scarcity and a lack of on-rails support. I would like to propose a different approach.

Extractors will wear out over time.

Basically, this is a function of how many running hours the equipment has been online and processing. It will result in a static decrease in reliability and output, eventually dragging down to zero (and a 'Broken!' status). This can be repaired through Kerbal EVA operations. So now you have an inconvenient choice. You can still run stuff on rails (until such time as it wears out and falls over), but you have to consider yield and cost (i.e. if your gear is only going to last 2-3 years, you may want to drop it on a hotspot with significantly better gains). Alternatively, you can land on a crappy spot and increase yield if you're willing to constantly EVA and keep the equipment operating at top efficiency.

Lastly, efficiency comes at a cost and requires ReplacementParts. These are not cheap, and have to be hauled in (or manufactured if you have MKS).

The net result should be gentle encouragement to consider efficiency, but still allow players to throw efficiency and cost to the wind and just go mine stuff.

Thoughts?

Basically a nice idea. I had two thoughts, though:

1. There should be enough time (like 3 years, yep) until it breaks completely. Very low efficiency is fine, but I’d like to have some weeks/months (extractor active time) of “MIR†operations with stuff working barley good enough for some minor emergency refueling but no real harvesting.
   
2. Ippo’s DangIt! Mod is quite popular and uses "SpareParts" to repair on EVA. Maybe we can again avoid resource fragmentation and use the same?
   

[nli2work]

If symmetry causes asymmetric behavior this is hopefully a bug in the game and not meant as a nice game challenge. If symmetry really is the cause there is a 'break symmetry' mod that might help. I've also read that flameout starts at either the first or the last engine you put on the craft, so if that is centered you can put others any way you want.

Asymmetrical flameouts happen in upper atmosphere where air intake rate begins to fall below consumption rate. When vessel is not perfectly aligned to velocity vector, side intakes get differing amounts of IntakeAir. Total IntakeAir pool is not enough to feed all the engines adequetly. Engine gets priority to IntakeAir from closest Intake (itself), and that leads to asymmetrical flame outs and flat spins.

it would be a problem if the thrust is asymmetrical even if the engines are placed with symmetry on. I hope this is not the case.

[RoverDude]

Basically a nice idea. I had two thoughts, though:

1. There should be enough time (like 3 years, yep) until it breaks completely. Very low efficiency is fine, but I’d like to have some weeks/months (extractor active time) of “MIR†operations with stuff working barley good enough for some minor emergency refueling but no real harvesting.
   
2. Ippo’s DangIt! Mod is quite popular and uses "SpareParts" to repair on EVA. Maybe we can again avoid resource fragmentation and use the same?
   

Concur on point 1.

For point 2, Ippo is more than welcome to request his resource be added to CRP, otherwise I'll go with a CRP resource.

[nli2work]

speaking of resources... is there a reasonable way to consolidate Squad's IntakeAir; KSPI's IntakeAtm; and Karbonite's ScoopedAir in code? they are all essentially the same thing, just filtering for different stuff that's part of the planet's atmosphere.

[RoverDude]

speaking of resources... is there a reasonable way to consolidate Squad's IntakeAir; KSPI's IntakeAtm; and Karbonite's ScoopedAir in code? they are all essentially the same thing, just filtering for different stuff that's part of the planet's atmosphere.

I'm already switching Karbonite to IntakeAtm and deprecating ScoopedAir. The only issue with using IntakeAir for, say, Karbonite, is that we'll suddenly enable stock jets to fly on Jool

Not saying that's a bad thing... but it is a thing

[marce]

Concur on point 1.

For point 2, Ippo is more than welcome to request his resource be added to CRP, otherwise I'll go with a CRP resource.

Not a big deal, I can't use his mod anyway because PP tanks aren't recognized. Simply wanted to point out that two similar resources exist.

Anyway, I'm already planning fully automated bases with rovers exchanging worn out extractor modules with fresh ones.

I'd love to build (less efficient) repair probes as well, but iirc actions on other vessels can only be activated on EVA...

EDIT: just for clarification: once the tanks are full and the extraction stops the "wear out" timer stops as well, right?

I'm already switching Karbonite to IntakeAtm and deprecating ScoopedAir. The only issue with using IntakeAir for, say, Karbonite, is that we'll suddenly enable stock jets to fly on Jool

Not saying that's a bad thing... but it is a thing

And IntakeAir sounds much more like an oxygen supply than IntakeAtm. So I second the separation.

[RoverDude]

Not a big deal, I can't use his mod anyway because PP tanks aren't recognized. Simply wanted to point out that two similar resources exist.

Anyway, I'm already planning fully automated bases with rovers exchanging worn out extractor modules with fresh ones.

I'd love to build (less efficient) repair probes as well, but iirc actions on other vessels can only be activated on EVA...

EDIT: just for clarification: once the tanks are full and the extraction stops the "wear out" timer stops as well, right?

And IntakeAir sounds much more like an oxygen supply than IntakeAtm. So I second the separation.

Oh... I have plans for automated repair drones. Basically, a rework of proxy logistics. But then... who repairs the drones?

[marce]

Oh... I have plans for automated repair drones. Basically, a rework of proxy logistics. But then... who repairs the drones?

Moar drones!!

[nli2work]

I'm already switching Karbonite to IntakeAtm and deprecating ScoopedAir. The only issue with using IntakeAir for, say, Karbonite, is that we'll suddenly enable stock jets to fly on Jool

Not saying that's a bad thing... but it is a thing

IntakeAtm is just IntakeAir with ModuleResourceIntake's checkForOxygen = false; so any gas will do for the engine. It's problematic if ModuleResourceIntake will only add to the resource if there is Oxygen. versus a simple check to allow engines to draw from resource if there is Oxygen. I haven't confirmed, but I believe if checkForOxygen is set to false; the engine will take any atmosphere, instead of only Laythe and Kerbin; same way IntakeAtm works.

Not trying to sound contrairian; just asking naive questions based on my meager understanding of the source code and config files.

Edited August 16, 2014 by nli2work

[RoverDude]

IntakeAtm is just IntakeAir with ModuleResourceIntake's checkForOxygen = false; so any gas will do for the engine. It's problematic if ModuleResourceIntake will only add to the resource if there is Oxygen. versus a simple check to allow engines to draw from resource if there is Oxygen. I haven't confirmed, but I believe if checkForOxygen is set to false; the engine will take any atmosphere, instead of only Laythe and Kerbin; same way IntakeAtm works.

Not trying to sound contrairian; just asking naive questions based on my meager understanding of the source code and config files.

No worries at all, I shall fiddle with this.

[somnambulist]

Oh... I have plans for automated repair drones. Basically, a rework of proxy logistics. But then... who repairs the drones?

... Bees? (10-char)

[Stage]

In Karbonite Pre0.3.0, do the Karbonite drills now support Ore and Mineral extraction by default, or are still MM patches needed?

[nli2work]

Looks like KSPI compatibility issue is resolved? I'm not getting any issues major or minor, with the Karbonite engines, nor with mine. No NREs related to FNPlugin.AtmosphericIntake in output_log.txt. An extra line of green bar in the right click window is small price to pay. Hurray!

One thing with the LF Propfan, the FSengineSound module audio paths need updated to the new part folder names.

[rabidninjawombat]

In Karbonite Pre0.3.0, do the Karbonite drills now support Ore and Mineral extraction by default, or are still MM patches needed?

looks like MM patches are still needed, if they are running Karbonite ONLY: The karbonite that comes with MKS/OKS does include modified drills for extraction.

[rabidninjawombat]

Sorry for the double post, just a syntax question on the new converter code being used in karbonite

MODULE
{
     name = USI_Converter
     converterName = LiquidFuel
     conversionRate = 1
     inputResources = ElectricCharge, 1.5, Karbonite, 0.9
     outputResources = LiquidFuel,0.9,False

What effect do the conversion rate field and the false tag after output resources have, everything else is pretty self explanatory.

Also can the converter do two output resources? and i assume its just comma delenated? or do i need a second outputResources line?

Sorry bout the noobish questions

Edited August 16, 2014 by rabidninjawombat

[Stage]

The new converter works like the TACLS converter.

conversionRate: will multiply inputs/outputs by that number.

The "false" tag means it will stop producing LiquidFuel if full (true means excess products will be voided)

Edited August 16, 2014 by Stage

[rabidninjawombat]

The new converter works like the TACLS converter.conversionRate: will multiply inputs/outputs by that numberthe "false" tag means it will stop producing LiquidFuel if full (true means excess products will be voided)

Thank you sir. Shoulda looked at the TACLS converter first, i remember it being said it was based on it.

[Geschosskopf]

Officially I'll keep it without bottom stack node. like other stock turbojets. Nothing prevents you from editing your config to add stack node however. just remember to change the attachment rules to allowStack.

Except I don't know how.

Besides, Karbonite should aspire to being better than stock, so should have nodes on the tailpipes of its jets.

And anyway, if you don't put a node on the tailpipe, the so-called "stack" version of the jet really can't be stacked so should be renamed "radial only without the pylon" .

Asymmetrical flameouts happen in upper atmosphere where air intake rate begins to fall below consumption rate. When vessel is not perfectly aligned to velocity vector, side intakes get differing amounts of IntakeAir. Total IntakeAir pool is not enough to feed all the engines adequetly. Engine gets priority to IntakeAir from closest Intake (itself), and that leads to asymmetrical flame outs and flat spins.

Actually, asymmetrical flameouts are caused by the order of part attachment to the vehicle. This was demonstrated by kashua in great and thorough detail. If you put the parts on in order intake, intake, engine, engine (using 2x symmetry for both), the 1st engine hogs all the air from both intakes, so when the total intake input becomes less than required by both engines, the 2nd engine will flameout while the 1st engine will keep running. So you have to add the parts intake, engine, intake, engine, 1 at a time, instead of using symmetry. That way, each engine has its own intake and remains happy, and both run out of intake resource simultaneously.

This of course is when the intakes and engines are separate parts, as with stock parts. But with the stock parts, you can make nacelles of engine and intake parts combined, and attach such subassemblies using symmetry, and all works well because the order of parts is still intake, engine, intake, engine.

That's why I mentioned this. The radial engines are combined intakes and engines, but attaching them with symmetry breaks their order of attachment somehow, so that the 1st engine gets both intakes and the 2nd engine flames out first. Not being a modder, I have no idea how to fix this, so if it can be fixed at all while retaining the combined intake-engine nature of the parts, it has to be done on your end. If this can't be done, then I suggest you remove the built-in intake from the radial engines and make players stick on separate intakes, so they can make subassemblies and put them on symmetrically like with stock parts, and get symmetrical flameouts.

[RoverDude]

In Karbonite Pre0.3.0, do the Karbonite drills now support Ore and Mineral extraction by default, or are still MM patches needed?

There's a folder - Karbonite PartsPack or something like that - that includes this. MKS is not required, it's a CRP thing now,

Looks like KSPI compatibility issue is resolved? I'm not getting any issues major or minor, with the Karbonite engines, nor with mine. No NREs related to FNPlugin.AtmosphericIntake in output_log.txt. An extra line of green bar in the right click window is small price to pay. Hurray!

One thing with the LF Propfan, the FSengineSound module audio paths need updated to the new part folder names.

Lemme fix that

looks like MM patches are still needed, if they are running Karbonite ONLY: The karbonite that comes with MKS/OKS does include modified drills for extraction.

Incorrect see above

[Donziboy2]

Except I don't know how.

Besides, Karbonite should aspire to being better than stock, so should have nodes on the tailpipes of its jets.

And anyway, if you don't put a node on the tailpipe, the so-called "stack" version of the jet really can't be stacked so should be renamed "radial only without the pylon" .

Actually, asymmetrical flameouts are caused by the order of part attachment to the vehicle. This was demonstrated by kashua in great and thorough detail. If you put the parts on in order intake, intake, engine, engine (using 2x symmetry for both), the 1st engine hogs all the air from both intakes, so when the total intake input becomes less than required by both engines, the 2nd engine will flameout while the 1st engine will keep running. So you have to add the parts intake, engine, intake, engine, 1 at a time, instead of using symmetry. That way, each engine has its own intake and remains happy, and both run out of intake resource simultaneously.

This of course is when the intakes and engines are separate parts, as with stock parts. But with the stock parts, you can make nacelles of engine and intake parts combined, and attach such subassemblies using symmetry, and all works well because the order of parts is still intake, engine, intake, engine.

That's why I mentioned this. The radial engines are combined intakes and engines, but attaching them with symmetry breaks their order of attachment somehow, so that the 1st engine gets both intakes and the 2nd engine flames out first. Not being a modder, I have no idea how to fix this, so if it can be fixed at all while retaining the combined intake-engine nature of the parts, it has to be done on your end. If this can't be done, then I suggest you remove the built-in intake from the radial engines and make players stick on separate intakes, so they can make subassemblies and put them on symmetrically like with stock parts, and get symmetrical flameouts.

If I recall correctly Fractal_UK did some coding magic on the KSPI thermal turbojets so that the thrust would reduce as you ran out of IntakeATM, preventing flameouts. Not sure if that is something that should be applied in this case or left as is.

[nli2work]

Except I don't know how.

Besides, Karbonite should aspire to being better than stock, so should have nodes on the tailpipes of its jets.

And anyway, if you don't put a node on the tailpipe, the so-called "stack" version of the jet really can't be stacked so should be renamed "radial only without the pylon" .

It's stack because it uses stack node to attach to the rest of the vessel. not using surface attach node. Has nothing to do with whether you can attach more on the end of it or not.

This of course is when the intakes and engines are separate parts, as with stock parts. But with the stock parts, you can make nacelles of engine and intake parts combined, and attach such subassemblies using symmetry, and all works well because the order of parts is still intake, engine, intake, engine.

I see what you mean, the main purpose of the intake is to make the engines useble with FAR/NEAR; I didn't anticiplate it would lead to the issue you are experiencing, thanks for making me aware of it. I think the new update will fix the asymmetrical flameout problem.

here I got 2x LF engines from Karbonite Pre 0.3.0, and I've closed the intake on the left engine. Both are running fine. no asymmetrical flameout.

Following previous image, I close the right engine intake. symmetrical flameout results now that there is no open intake on the craft.

Edited August 17, 2014 by nli2work

[Geschosskopf]

If I recall correctly Fractal_UK did some coding magic on the KSPI thermal turbojets so that the thrust would reduce as you ran out of IntakeATM, preventing flameouts. Not sure if that is something that should be applied in this case or left as is.

Squad did the same in whatever update introduced the RAPIER engine. Although the throttle indicator beside the navball doesn't move, under the hood jet engines throttles down as IntajeAir decreases, thus showing thrust decreasing over time if you have the right-click menu open. This is why since that update SSTOs have been much easier to do, as the player no longer has to throttle back manually and the computer's control of the throttle is more precise and fine-tuned.

I should point out that despite this fundamentally Squad thing presumably still going on in the background, the Kerbonite jets act like old-school (pre-0.23?) SSTOs. That is, by carefully throttling back manually as you see the ScoopedAir bar start to decrease, you can work them up to over 40km doing and about 2000m/s. I have no problem with this because this nostalgic bit of SSTO-pilot9ing skilz keeps me from feeling the Karbonite jets are OP due to their sky-splitting thrust.

But all this is really beside the point I was trying to make. No matter if the engines throttle back by themselves or not, symmetrical flameout (assuming the thing is going prograde with respect to the yaw axis) is totally dependent on the order of intake and engine parts in the craft file. To the extent that combined intake/engine parts don't follow the game engine's approved part order for symmetrical flameout, they will always cause asymmetrical flameout.

Edited August 17, 2014 by Geschosskopf

[Geschosskopf]

I see what you mean, the main purpose of the intake is to make the engines useble with FAR/NEAR; I didn't anticiplate it would lead to the issue you are experiencing, thanks for making me aware of it. I think the new update will fix the asymmetrical flameout problem.

here I got 2x LF engines from Karbonite Pre 0.3.0, and I've closed the intake on the left engine. Both are running fine. no asymmetrical flameout.

Following previous image, I close the right engine intake. symmetrical flameout results now that there is no open intake on the craft.

Kudos to you, sir!