Kethane Pack 0.9.2 - New cinematic trailer! - 1.0 compatibility update

[NathanKell]

No KhaosCorp, *you're* not understanding. S/he's talking about GAME time. You know, the clock in the upper left. Not how long it takes the human being in front of the computer--high orbit, high time warp, etc helps here--but how long it takes the satellite in KSP-time. Which is at its minimum in low orbit, because the orbital period is shortest. What you're suggesting makes things _worse_ from the perspective of game time, even though it helps in real time.

[KhaosCorp]

No KhaosCorp, *you're* not understanding. S/he's talking about GAME time. You know, the clock in the upper left. Not how long it takes the human being in front of the computer--high orbit, high time warp, etc helps here--but how long it takes the satellite in KSP-time. Which is at its minimum in low orbit, because the orbital period is shortest. What you're suggesting makes things _worse_ from the perspective of game time, even though it helps in real time.

Re-read my post, if done right my method of scanning takes less GAME TIME as well.

I understand full well what game time is thank you.

How many hours of REALTIME have you devoted to kethane scan testing Nathan, Im curious??

[rottielover]

I updated to the new version (I deleted the Kethane folder under GameData and replaced it with the download), but now my scanners are not updating the grid and I don't hear the tones. I can right click and activate them but they don't seem to be mapping. I used the prior version with no issues

[ewolfe13]

I have the same problem.

[ewolfe13]

I updated to the new version (I deleted the Kethane folder under GameData and replaced it with the download), but now my scanners are not updating the grid and I don't hear the tones. I can right click and activate them but they don't seem to be mapping. I used the prior version with no issues

I am having the same problem. Anyone know what's causing it?

[Frederf]

Khaos is saying that multiple scanners have their sample intervals automatically staggered so that at high warp what would normally be a spotty-skippy sampling by one scanning device has no (or fewer) holes with multiple scanning devices.

This means at high time acceleration less time (both kinds) pass for a complete sample. However at 1x time acceleration I think the multiple scanners don't help because only one device leaves no holes so the advantage is lost.

[KhaosCorp]

Khaos is saying that multiple scanners have their sample intervals automatically staggered so that at high warp what would normally be a spotty-skippy sampling by one scanning device has no (or fewer) holes with multiple scanning devices.

This means at high time acceleration less time (both kinds) pass for a complete sample. However at 1x time acceleration I think the multiple scanners don't help because only one device leaves no holes so the advantage is lost.

100% correct!!

Though I left out the bit about x1 time warp, since we were talking about fast scans I assumed no one was trying it on x1 warp =)

Also, a 'full' scan is very over-rated...its a mindset that comes from using ISA i think. But with Kethane (and EPLP) it is NEVER nedded to get a full map (unless your ocd like me and cant stand the little gaps). Even if you plan on sucking a planet/moon dry of kethane a 100% full map is not needed, you will see part of every deposit there is bytime the map is 2/3s full (if your orbital parameters are ideal).

I should be slapped for not putting this in by now, but your AP/PE altitudes and your inclination has a HUGE effect on scanning. Its a combination of ALL these aspects to get fast scans...this is why I have done so much testing in regards to this. Its not a RONCO oven..no set it and forget it. all these little parameters have to be dialed in just right for an ideal scan.

[Frederf]

I considered using the phrase "more complete."

In any case I'm about to do the math that asks how what orbit has what period such that the Mun turns one hex-width underneath me every polar orbit. However the upgrade from .74 to .75 has left my Ke mod borked so I'll have to fix that first.

Fix: As per post 2371 a simple save/reload fixed it.

Math: Each hex appears to be 2.2° apart. The Mun has a rotation period of 138 984.38s. This means it does 2.2° in ~849.35s or 14m9.35s. Such an orbit is not possible above the surface of the Mun. However by tripling this one can orbit at 42:29 (20.5km) which is about a second slow for triple.

Edited August 8, 2013 by Frederf

[NathanKell]

But the point is if you're at an altitude where you can run high enough time warp to need large quantities of scanners, you're too high for game-time-optimal scanning, since that depends on orbital period.

Whether you're going full-OCD or just want a good guess at locations, you're still going to be better off, game-time wise, using a lower altitude, because your period will be lower so you'll be circling Kerbin faster (in game time terms).

Kethane is, indeed, NOT mapsat. So you only grab one hex at a time. That means altitude doesn't matter for resolution, which means you want the lowest altitude (and therefore lowest period) to get the most hexes in the least gametime.

You want to test this? You build your 10k timewarp scanner and put it nice and high for 10k timewarp. I'll build my 70km alt scanner. We'll see who's scanned more hexes after six hours game time.

[KhaosCorp]

But the point is if you're at an altitude where you can run high enough time warp to need large quantities of scanners, you're too high for game-time-optimal scanning, since that depends on orbital period.

Whether you're going full-OCD or just want a good guess at locations, you're still going to be better off, game-time wise, using a lower altitude, because your period will be lower so you'll be circling Kerbin faster (in game time terms).

Kethane is, indeed, NOT mapsat. So you only grab one hex at a time. That means altitude doesn't matter for resolution, which means you want the lowest altitude (and therefore lowest period) to get the most hexes in the least gametime.

You want to test this? You build your 10k timewarp scanner and put it nice and high for 10k timewarp. I'll build my 70km alt scanner. We'll see who's scanned more hexes after six hours game time.

I HAVE tested this before...I have done over 50hrs of REALTIME testing for the best way to scan..all of this was done just after the changes to how the scanners worked. I have done basically the exact test you talking about at least 15 times...probably more. But I encourage YOU to do this test. IMO the only way to know for sure in KSP is to do it yourself! That's why 2/3 of my gametime in KSP is strictly testing, the other 1/3 actually doing missions.

[Geschosskopf]

Khaos:

I'm really curious here. Suppose you launch a ship to Duna and when you 1st leave, before you warp for the long coast, it says it will take say 70 game days to get there. OK, so you warp 10Kx or even 100Kx until you reach Duna's SOI. So, how many game days will have passed since you left Kerbin? If you say anything other than 70 game days, you'll be wrong. Even though you warped at 100Kx for the entire trip and it only took a few minutes of real time, it still took a full 70 days of GAME time. Doesn't matter whether you warp or not or how much, warping does not change the speed of your ship.

So how can you possibly think scanning for Kethane is any different? Just curious.

[Frederf]

Because the trip is longer for mutli-scanning as one must conduct more orbits. He's comparing high-warp single sensor vs high-warp multi sensor.

[Majiir]

Just to throw in another wrench: since scanning scales logarithmically with timewarp, all else held equal going to higher time warp makes scanning take less real time and more game time. Of course, if your satellite is built such that going to that higher time warp reduces idle time, you may not be incurring a game time penalty, but you also won't make it faster.

[KhaosCorp]

Khaos:

I'm really curious here. Suppose you launch a ship to Duna and when you 1st leave, before you warp for the long coast, it says it will take say 70 game days to get there. OK, so you warp 10Kx or even 100Kx until you reach Duna's SOI. So, how many game days will have passed since you left Kerbin? If you say anything other than 70 game days, you'll be wrong. Even though you warped at 100Kx for the entire trip and it only took a few minutes of real time, it still took a full 70 days of GAME time. Doesn't matter whether you warp or not or how much, warping does not change the speed of your ship.

So how can you possibly think scanning for Kethane is any different? Just curious.

If you wanna debate scanning tactics I'm all for it...the second you start to insult my intellect I'm done with you. I understand very well how the passage of game time works..you seem to not understand how the Kethane scanners work....have a nice day.

[Rassa Farlander]

Hi peeps! Ive been staring at this mod for months and I finally downloaded to day Great work Majir and friends! The popularity of this mod has always kept my interested so I thought Id try it out. Ive got some of Kerbin scanned and most of the Mun and Minmus and Im ready to start some drilling! Im just not sure where to begin. Ive look a little bit at the Wiki and read through some of this forum thread, but Im still a little overwhelmed lol. So any pro-tips to help me get started? Does a drill rig need a scanner? Whats best a mobile rover rig or stationary? Im not sure where to start lol Thanks

[JewelShisen]

Well my advice would be to have a scanner on the ship for two reasons: First to make sure you land on the deposit and second to monitor the remaining resource level of said deposit.

As for the mobile vs stationary question my answer is a question. What do you want this drill rig to do? What is it's purpose?

[smunisto]

Well my advice would be to have a scanner on the ship for two reasons: First to make sure you land on the deposit and second to monitor the remaining resource level of said deposit.

As for the mobile vs stationary question my answer is a question. What do you want this drill rig to do? What is it's purpose?

Both of your suggestions are covered by the new kethane map. The hex grid has quantities, which are actively updated, so you can track the amount of kethane left in real time.

The grid also shows accurately where you have landed(or fairly, because of the map height over the surface).

[JewelShisen]

I wasn't aware that the grid updated in real time without an active scanner.

Also the grid doesn't show where you landed, the map does. The grid only gives you a rough idea of where the kethane is located. Though now that i think on it, the scanner wouldn't do you any good for landing anymore as it would just check the whole hex now.

[Rassa Farlander]

Well I would like to go for efficiency, in parts and fuel consumption I suppose. I was going to make a rig that lands and drills and stores then have something else come and get it and then haul it to a station with the converter stuff on it and lots more storage. Although still having trouble with designs and getting stuff going. I think Ive got scanning figured out more or less though

[Crater]

Well, drills, converters, and the power supplies for them are heavy, so if you want efficiency, I would suggest that you have a semi-permanent installation that you can land on a deposit which has the drilling and converting hardware onboard, enough fuel tankage (&RCS) only for its own needs, and a small amount of kethane storage space, mostly as a buffer for the converter. If you equip that vessel with KAS, you can then very easily land tankers, that have nothing but lots of storage space for the material you are interested it (a fuel tanker, an RCS tanker, a Kethane tanker, etc.) close to the drilling rig, which can connect up a hose, suck the green goop out of the ground, convert it to whatever you are after, and pump it straight into the waiting tanker, it doesn't need much storage on the drilling vessel.

This means that your tankers will only be lifting to orbit the essentials - their own fuel, engines, etc. plus their cargo.

Other people swear by the all-in-one design, where the tanks are on the driller/converter rig, which simplifies the process, but does use more fuel as you are lifting more weigh more often.

[Rassa Farlander]

Hmmm Ive never used KAS I think Ive heard of it though. I think thats kinda along similar line of what I was thinking also but Ive heard Kethane has a lower density than fuel and I dont want my tugs eating my finished product and that why I was thinking convert in orbit, but Im still not sure. That being said Ive had a couple failed landers already, I do like this though, it has brought some challenge back to KSP

[Crater]

Lower density doesn't actually help. When it comes to lifting, it is mass that matters, not volume, so shipping Kethane instead of fuel just means that you have to have more tanks to get the same total amount of final resource to orbit, which makes the vessel bigger, and usually less maneuverable for docking.

There is also conversion efficiency to consider. For example, using a small converter, the efficiency for monopropellant is 0.3 - that would mean that for every ton of monopropellant that you create in orbit, you would have had to lift 3.3 tons of Kethane up to orbit. Even with the large converter, it only runs at 0.85 efficiency for monopropellant, so you're wasting 15% of your lifted mass compared to converting on the surface.

That said, it is always a lot more flexible to keep Kethane on hand in orbit, so that you can, e.g. refuel xenon into an ion probe if you need to, without having to keep xenon stocks on hand at all times.

[Crater]

While I was looking at whether it was more efficient to lift Kethane to orbit, or to convert it on the ground, I was doing some maths with the converter stats, and I've found what appear to be some discrepancies with the small vs large converters.

First of all, using the large converter to generate at 45/55 mix of liquid fuel and oxidizer actually gains mass, the weighted average of the efficiencies is 1.008, compared to the small converter at 0.992. The large converter runs at about three times the speed, and uses about 65% of the power per unit produced. That's all good apart from the mass-efficiencies looking a little high.

For monopropellant the mass-efficiency leaps from 0.3 to 0.85, a huge boost for the large converter, with the large generating at 5.7 times the rate, while only using 22% of the power per unit produced. This is a much better case than LF/OX.

For Xenon, things get a little squirrelly.

The conversion efficiency actually drops from 0.4 to 0.25, which means that the large converter takes 60% more Kethane than the small, to produce each unit of xenon. This also means that the large converter only produces xenon at 83% of the speed of the small converter, and that it uses over 300% of the energy to do so. No wonder it runs hot

Is there a rationale behind these numbers, or is it just a case of them not (yet) having been balanced properly?

[Superkalashnikov]

The amount of posts is incredible. The one forum of another game is such smaller.

This mod pack is very very very good.

[Geschosskopf]

Just to throw in another wrench: since scanning scales logarithmically with timewarp, all else held equal going to higher time warp makes scanning take less real time and more game time. Of course, if your satellite is built such that going to that higher time warp reduces idle time, you may not be incurring a game time penalty, but you also won't make it faster.

What's the chance of you being able to make the scanned path wider with higher altitude, as if the scanner beam is cone-shaped? Doing so would resolve the current conflict where reducing game time increases real time and vice versa. For instance, if you gave the scanner the same beam width as the ISA MapSat, with a proper orbit you could reduce the game time required to 15-20 hours instead of the current 7 days, while at the same time being far enough out from the planet to use 100x or higher warp, thereby also reducing real time.