[24.2] Karbonite Ongoing Dev and Discussion

[RoverDude]

i like scansat, i like the resource overlay and the maps. The only problem i have is to translate the position of a deposit/anomaly/whatever from scansat to the mapview/planetview. The map is detailed but the mun/planetview is not that much.

I guess thats why people would like to have a overlay on the mapview. Makes things easier.

Ok so to paraphrase the last few posts... the sticky point is that once we find a spot we like in SCANSat, it's a challenge to translate that spot to the map for landing.

[Crater]

Ok so to paraphrase the last few posts... the sticky point is that once we find a spot we like in SCANSat, it's a challenge to translate that spot to the map for landing.

I can't speak for the others, but that's my hang-up, yeah.

[KerbinDallas]

Aweesome, so here's a follow up.

How would you feel if, in map mode, you got the entire map at once (as that's how the ORS hotspot code works)? Does this make you sad? I say this because the two mods (Kethane and Karbonite) are so fundamentally different that trying to make one become the other is just asking to take on a giant pain ball.

For real I see what you're saying, but I think this:

*snip

What would people think about waypoints instead? If you could select a location in the scansat map view, and a waymarker was laid onto the planet at that point, so you could easily see it on the ground. I know it's possible already if you transpose the coodinates into MechJeb, for example, but a clean interface to drop BIG FRIENDLY LABELS onto the planet view might solve the navigation problems without being a massive coding effort, and be much nicer on resources (of the computer variety).

This is a great idea.

[RoverDude]

For real I see what you're saying, but I think this:

This is a great idea.

No debate, that would be one killer feature. But it would be one for the ScanSat guys to do (or at least provide the API for that I could reach into)

[Donziboy2]

No debate, that would be one killer feature. But it would be one for the ScanSat guys to do (or at least provide the API for that I could reach into)

Use mechjeb landing guidance, put in the coordinates and bobs your uncle.

You get an arrow on the coordinates and it will tell you where you will crash land if your in a suborbital.

[DMagic]

Lots of stuff

The current idea is to have some kind of waypoint generator for SCANsat; possibly through MechJeb, but also by clicking on a point on the map.

I think the simplest method is to generate a flag at that location. This will show up on the map, you can get its exact location by hovering over it, it's targetable, and it shows up on the navball. Doing this avoids the need for any kind of UI overlay on the screen or map mode, or any complex method for adding information to the navball. The flag could then be cleared from the map whenever you want, deleting the flag vessel and avoiding bloating the vessel list more than it already is.

Also; such suggestions would do much better on the SCANsat threads, or better yet on the GitHub issues page, or even better still, do it yourself and submit a pull request.

[Alvin853]

I have some concerns about the use of MW the way you're using it now. In my opinion it should be changed to kW for two reasons:

1. KSPI uses the definition 1kW = 1 Electric Charge per second, while Karbonite seems to use 1MW = 1 EC/s. Going by production/consumption of stock parts I think the KSPI definition is the correct order of magnitude.

2. The cute little Karbonite generator outputs 250MW of electric power, or about 1/4 of a typical commercial nuclear reactor. This is just not feasible with current Earth technology which seems to be pretty similar to Kerbal technology. Again 250kW would be a much more realistic number.

[Donziboy2]

I have some concerns about the use of MW the way you're using it now. In my opinion it should be changed to kW for two reasons:

1. KSPI uses the definition 1kW = 1 Electric Charge per second, while Karbonite seems to use 1MW = 1 EC/s. Going by production/consumption of stock parts I think the KSPI definition is the correct order of magnitude.

2. The cute little Karbonite generator outputs 250MW of electric power, or about 1/4 of a typical commercial nuclear reactor. This is just not feasible with current Earth technology which seems to be pretty similar to Kerbal technology. Again 250kW would be a much more realistic number.

MW has already been discussed more then once, I believe Rover plans on going back to EC's to reduce confusion.

[RoverDude]

MW has already been discussed more then once, I believe Rover plans on going back to EC's to reduce confusion.

Correct, there was probably already the pull request somewhere

[Akira_R]

Use mechjeb landing guidance, put in the coordinates and bobs your uncle.

You get an arrow on the coordinates and it will tell you where you will crash land if your in a suborbital.

Thing is I personally hate mechjeb, never use it, and I've always had issues with it, I play on a laptop thats about a year old and it will run the game with EVE and Astros pack and distant object enhancements and a whole heap of other mods just fine on lower settings, the second I put a MJ component on a rocket though it cuts my frame rate in a half

The current idea is to have some kind of waypoint generator for SCANsat; possibly through MechJeb, but also by clicking on a point on the map.

I think the simplest method is to generate a flag at that location. This will show up on the map, you can get its exact location by hovering over it, it's targetable, and it shows up on the navball. Doing this avoids the need for any kind of UI overlay on the screen or map mode, or any complex method for adding information to the navball. The flag could then be cleared from the map whenever you want, deleting the flag vessel and avoiding bloating the vessel list more than it already is.

Also; such suggestions would do much better on the SCANsat threads, or better yet on the GitHub issues page, or even better still, do it yourself and submit a pull request.

This right here sounds amazing, I've been wanting some way to set way points through SCANsat for ages!!!! If someone could do this they would be my hero!!!!

[bpuk]

MW has already been discussed more then once, I believe Rover plans on going back to EC's to reduce confusion.

Correct, there was probably already the pull request somewhere

Alas, the string MW comes from two different places. One is from within the Karbonite code and is easy to change. The other is in ORSModuleResourceExtraction. While changing to EC/s has been agreed, this one is on hold until we decide how we're going to handle ORS.

[KerbinDallas]

The current idea is to have some kind of waypoint generator for SCANsat; possibly through MechJeb, but also by clicking on a point on the map.

I think the simplest method is to generate a flag at that location. This will show up on the map, you can get its exact location by hovering over it, it's targetable, and it shows up on the navball. Doing this avoids the need for any kind of UI overlay on the screen or map mode, or any complex method for adding information to the navball. The flag could then be cleared from the map whenever you want, deleting the flag vessel and avoiding bloating the vessel list more than it already is.

Also; such suggestions would do much better on the SCANsat threads, or better yet on the GitHub issues page, or even better still, do it yourself and submit a pull request.

I think you're right, that's a pretty solid idea and it's proven to work. It would also make sense to drop a rover with something like the surface sample experiment from MKS or from your own surface experiments, then you have a target-able ship on the map and the info on the navball. I personally don't think the overlay from ORS or really any overlay is necessary but I think to be able to see the ppm in mapmode once a planet is scanned or something would be a cool feature but again that's just me.

I don't really want to use mechjeb because my gamedata folder is filling up fast, I just got a little carried away with that idea because, well it's a cool idea although more suited to a SCANSat thread. I would totally do it but it's far beyond my own skill right now.

[bigbadben]

hhmm...the Fine Print mission mod has a waypoint generation system in it. But is it something Karbonite can use, or is it something that ScanSat/ORS would need to check out?

btw, will Karbonite work with OvenProofMars' StarSystems mod, when he updates it with planets? Will Karbonite dynamically spawn resources on the other planets, or is the only way, is to manually update the maps of the new planets/systems?

I'm thinking StarSystems, KSPI, Karbonite, MKS.....!

Edited August 15, 2014 by bigbadben

[RoverDude]

hhmm...the Fine Print mission mod has a waypoint generation system in it. But is it something Karbonite can use, or is it something that ScanSat/ORS would need to check out?

btw, will Karbonite work with OvenProofMars' StarSystems mod, when he updates it with planets? Will Karbonite dynamically spawn resources on the other planets, or is the only way, is to manually update the maps of the new planets/systems?

I'm thinking StarSystems, KSPI, Karbonite, MKS.....!

SCANSat makes the most sense tbh, as it's useful well beyond Karbonite.

RE other planets - the only way is to create new setups and maps for new planets.

[mortiphago]

A couple of things that I haven't seen mentioned in this thread and I'm not sure if they're bugs or just missing features:

A) drills and resource extraction can't be toggled via actiongroups

the converter turns off when electric charge = 0 , while resource extraction will pause and then resume when the batteries start charging again. It'd be nice if the converter would do the same, so that you don't have to interrupt the timewarp every time you run out of charge

C) the converter's speed is way too slow. As in, it takes a long while even in x1000 timewarp to chug through 3k worth of karbonite. (I've yet to try fiddling with the part's cfg but it should be at least 10 times faster, i think.)

Thank for your time guys, i'm loving this mod.

[bpuk]

A couple of things that I haven't seen mentioned in this thread and I'm not sure if they're bugs or just missing features:

A) drills and resource extraction can't be toggled via actiongroups

A quick test install of 0.24.2 with Karbonite 0.2.3 shows them to be working. If these are the versions you are using something about your install may be broken. The usual suspect is a duplicated install of OpenResourceSystem.

the converter turns off when electric charge = 0 , while resource extraction will pause and then resume when the batteries start charging again. It'd be nice if the converter would do the same, so that you don't have to interrupt the timewarp every time you run out of charge

C) the converter's speed is way too slow. As in, it takes a long while even in x1000 timewarp to chug through 3k worth of karbonite. (I've yet to try fiddling with the part's cfg but it should be at least 10 times faster, i think.)

Thank for your time guys, i'm loving this mod.

The converter code is being reworked at the moment. Once the new code is out it'll be interesting to take a look at these two.

[nli2work]

did the KSPI Experimental and Firespitter conflict ever get resolved? I think I'm making some progress in locating a solution.

[RoverDude]

A couple of things that I haven't seen mentioned in this thread and I'm not sure if they're bugs or just missing features:

A) drills and resource extraction can't be toggled via actiongroups

the converter turns off when electric charge = 0 , while resource extraction will pause and then resume when the batteries start charging again. It'd be nice if the converter would do the same, so that you don't have to interrupt the timewarp every time you run out of charge

C) the converter's speed is way too slow. As in, it takes a long while even in x1000 timewarp to chug through 3k worth of karbonite. (I've yet to try fiddling with the part's cfg but it should be at least 10 times faster, i think.)

Thank for your time guys, i'm loving this mod.

See below

A quick test install of 0.24.2 with Karbonite 0.2.3 shows them to be working. If these are the versions you are using something about your install may be broken. The usual suspect is a duplicated install of OpenResourceSystem.

The converter code is being reworked at the moment. Once the new code is out it'll be interesting to take a look at these two.

did the KSPI Experimental and Firespitter conflict ever get resolved? I think I'm making some progress in locating a solution.

Not that I have heard of - can always PM Wave, he's pretty responsive, and on the cusp of a new release

[nli2work]

test configs for those having Radial Turbofan and Propfan engine problems when using KSPI and Karbonite.

can safely overwrite the existing configs. if it doesn't fix the problem, it won't make it any worse. promise.

http://www./download/86ue53n4nlux42a/KaEnginesTest.zip

Edited August 16, 2014 by nli2work

[RoverDude]

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?

[RoverDude]

test configs for those having Radial Turbofan and Propfan engine problems when using KSPI and Karbonite.

can safely overwrite the existing configs. if it doesn't fix the problem, it won't make it any worse. promise.

http://www./download/86ue53n4nlux42a/KaEnginesTest.zip

Adding this to the pre-release. Are these good for final or do they have tons of weird testy-stuff in them?

[Sutima]

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?

YES!!!.

There are a lot of mods that add parts and new things to do, But few add Valuable long term content. Well this is it, and it adds a good platform for expanding upon it.

[nli2work]

Adding this to the pre-release. Are these good for final or do they have tons of weird testy-stuff in them?

nothing testy. all stock configs. just added stock Resource IntakeAir to engines, seemed like they were the source of KSPI incompatibility. It's similar to the 0 electric resource on stock engines. Resource is defined at 0; stock code adds tiny amount to the part when launched, enough not to trigger NaN error; but not enough to run the engine. Won't hurt anything, even if it doesn't solve the problem.

I thnk the gist of it is KSPI has new IntakeAtm resource, which is added to parts that has IntakeAir resource. All parts that consume IntakeAir are set to consume IntakeAtm as well. Problem came up when I added ModuleResourceIntake to make the engines FAR compatible, parts with intake have 0 drag in FAR. Without Intake module, the blades radius makes FAR think there's a huge flat disc trying to go really fast, and FAR says "hell no". I didn't define IntakeAir resource since I don't want the engine to go without using separate Air Intakes. KSPI sees the engines consume IntakeAir, and set them to consume IntakeAtm as well. of course, no IntakeAir resource defined means no IntakeAtm defined, which leads to NRE spam and/or NaN errors, which in turn makes KSP go crazy.

Edited August 16, 2014 by nli2work

[Geschosskopf]

I'm loving this mod. Thanks, guys! It's such a pleasant change to avoid the laborious and highly boring Kethane scanning .

I've got a bit of feedback.

1. If you're using Deadly Reentry, the ScoopedAir intakes (the separate parts, not those built into the radial engines) always burn up. And they don't let you attach parts to them radially, so you can't add heatsheilds to protect them. For the nonce I'm going to use ModuleManager to solve this problem but it's something you might want to look at in a future update.

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.

3. On Kerbin, ScoopedAir seems to remain constant up to about 25km, then goes away very quickly from there to 30km. This is regardless of the number of intakes used. Is that the way it's supposed to work? NOTE: Using NEAR.

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?

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 ).

[RoverDude]

I'm loving this mod. Thanks, guys! It's such a pleasant change to avoid the laborious and highly boring Kethane scanning .

I've got a bit of feedback.

1. If you're using Deadly Reentry, the ScoopedAir intakes (the separate parts, not those built into the radial engines) always burn up. And they don't let you attach parts to them radially, so you can't add heatsheilds to protect them. For the nonce I'm going to use ModuleManager to solve this problem but it's something you might want to look at in a future update.

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.

3. On Kerbin, ScoopedAir seems to remain constant up to about 25km, then goes away very quickly from there to 30km. This is regardless of the number of intakes used. Is that the way it's supposed to work? NOTE: Using NEAR.

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?

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 ).

Thanks for the info! I'll let nli2work address any engine things as he is our chief executive of all things that go boom. I'll tweak the intakes