[1.0.4] ESLD Jump Beacons - [Dev 0.6a]

[TMarkos]

Update, since I'd like to solicit some opinions. I've been noodling around with Blender trying to improve on some models and came up with a concept that I think will work for the LB-100 Longbow. Is this a good look, or would people prefer a static model?

https://gfycat.com/PotableUltimateDrake

I'd embed a gif, but it ends up looking like crap, very choppy. I'm also going to try to make individual models for the tech boxes rather than having them retextures of the same part model. Maybe I'll get really wild and do new models for the fuel tanks too.

Blender is immensely time-consuming when you don't know what you're doing.

[Katalliaan]

It's a smooth animation, although I'm not sure I understand the reason behind it opening like that.

[TMarkos]

It's a smooth animation, although I'm not sure I understand the reason behind it opening like that.

Well, the current designs have an exposed core that lights up. These would be protective doors over that area. I'll probably play around a bit more before I texture a model, at which point the beacon would be more recognizable.

[Xenro66]

Mother of complicated, yet realistic jump beacons! This is awesome!

[TMarkos]

Mother of complicated, yet realistic jump beacons! This is awesome!

Thank you! As it's still not quite finished I'm very open to any feedback you might have after trying it out.

[Xenro66]

Thank you! As it's still not quite finished I'm very open to any feedback you might have after trying it out.

Well, I'm still trying to figure out the best ways to use them

[MrBonobo]

Why, each time I have a stable and cool build on KSP, I found out a new mod that change my game perspectives and goal so radically? Why? Anyway, thanks a lot for this very nice and interesting mod!

[TMarkos]

Why, each time I have a stable and cool build on KSP, I found out a new mod that change my game perspectives and goal so radically? Why? Anyway, thanks a lot for this very nice and interesting mod!

Glad you like it! Please let me know any thoughts you have after trying it out.

[TMarkos]

A minor version release just went up containing the new Community Resource Pack bundled in, if you've updated it from other sources like CKAN you don't need to download it again. The major change insofar as ESLD Beacons is concerned is that the harvestable solar Karborundum (available with Karbonite+ solar collectors) is now at a less-lethal distance from the sun.

[Weywot8]

Just wanted to say I've discovered your mod and it's great! I've got the Outer Planet Mod (OPM) where travel can take decades - a functional colony on/around every planet is a real possibility now. The AMU is a nice touch as well, differentiates it from KSPI-E's warp drive in exchange for some initial travel time to the beacon. Still sandboxing at the moment and stuff works like as described.

Very small matter with the minimal activation altitude displayed, the actual min altitude is higher by a smidgen (+1.5k around Jool but seen around Eve, Kerbol, Kerbin in varying amounts), probably a rounding/float to integer display thing?

Some thoughts on balance vs. fun (CTT biased) -

• EC use at 3 stages instead of 2 in line with popular "SF logic".
  
  • EC for initiation independent of K+ but influenced by beacon size and local gravity. Get stuff online, spinning up stabilizers, initial anchoring of space-time within the beacon separate from local gravity, etc. Bigger beacon's need moar EC as a result. Need lotsa EC, many tens of thousands for LB-100 at baseline gravitational tolerance limit. Engineers lower EC cost. From a gameplay mechanic, being able to harvest K+ from Eve/Eeloo in stock sorta means hauling a few extra Z-4Ks (3 Z-4Ks = 12k EC) with the beacon isn't that big a deal. And batteries all go into orbit fully charged anyway.
    
  • EC for stand-by influenced only by local gravity. Have to keep those stabilizers spinning and isolating that slice of space-time. Engineers lower EC cost (sad to stick a Kerbal in the middle of nowhere but it gives people with life support mods something to think about)
    
  • EC for transfer influenced by K+ used but EC per unit K+ reduces with beacon size in keeping with LB-100 logic (cue hand-waving and air quotes). EC's being used to contain and direct the K+ detonation, connect to and power destination beacon. Bigger beacons need less EC per K+ the same way a long plank needs less force to break it in the middle vs. a shorter one. Scientists reduce K+, engineers reduce EC, pilot reduces distance/speed penalty. Jeb/Val, Bob and Bill all get to do something for the trip! As for gameplay, allows choice between hauling up fewer solar panels and "trickle" recharge between jumps vs shorter intervals between big ship jumps.
    
  • Further increase EC use near gravitational tolerance limit (see below) for balance/gameplay such as K+ harvesting near around Kerbol/Eve (affected by latest EC scaling on solar panels - one Gigantor produces 48.8EC/s at 175km around Eve) or choosing beacon location vs beacon infrastructure for planets far from Kerbol. Hauling a big space station docked with a fully equipped beacon, initiating then undocking the beacon and transferring the space station is still Kerbal-crazy do-able but the IB-1 becomes much more attractive as a goal/option.
    

• Using the GMU doesn't make much difference in minimum orbital height that can't be overcome with at most a few hundred m/s delta-V in planetary SOI and a bit more travel time. 25% gravitational tolerance looks big but the inverse square law means that's just a ~10% change in orbital SMA/~11-14% altitude reduction. Based on the charts, there are clear roles in mind for each beacon. Perhaps rescaling gravitational tolerances of beacons to in-SOI location/travel time can reinforce these roles? (no idea how to superscript, apologies for below)
  
  • for instance LB-100 at 6mm/s2 putting the minimum altitude between Minimus-Mun (4-5 days travel), +GMU to 60mm/s2 between Kerbin-Mun. Around Kerbol, that translates to unaugmented-just under Kerbin orbit (access to outer planets only and big ships still have to planet-hop around to get to the other side of Kerbol) and +GMU gives a radius that's within Moho's orbit most of the time (inner planets + trans-Kerbol access). Adds a nice touch to delay heavy ships beaconing direct into Kerbol-Eve for K+
    

• then LB-10 would be 0.6m/s2 (~1800km, an hour away from Kerbin) to +GMU 6m/s2 (160km altitude, just above 1.25r limit). Transferring from a minimum altitude LB-10 to LB-100 saves a big chunk of time and is a "must do" for big ships. Coming back in, an LB-10 based at LB-100 min altitude transferring all the way down to Kerbin saves the same amount of time.
  
  • noticed that even without these changes, the underlying mechanics encourage linking two beacons together to eliminate a transfer step (outermost on your gravity chart)
    
  • ... since it becomes a stop over, might add a science lab
    
  • ...and some ore processing/refueling station
    
  • ...and look, a station contract to finance the whole thing!
    
  • thinking along these lines, any added parts to fulfill the EC suggestions from before don't impose much of a burden, but that's just me I suppose
    

  [*]LB-15 filling the gap with 60mm/s2 unaugmented, i.e. 0.06m/s2, to +GMU to 0.6m/s2. Small ships get to go to inner planets, use trans-kerbol path off the bat but still need to travel some distance to the beacon to begin with so LB-10 to LB-15 transfers are still useful. These tolerances also seem make sense around Duna, Jool too.

• the large suggested orbit differences from using the GMU provide a noticable gameplay change - the option of reducing K+ use in planetary SOI by direct travel. That's balanced against the fact that smaller orbits produce a larger range of velocity differences, potentially incurring a larger AMU K+ cost by those who really want to save time, keeping in line with your design principles for this mod
  
• could I see the underlying formulae for the various K+, EC, altitude reduction numbers? Rather curious, if you don't mind that is.
  

Realized along the way that the best potential reward for hauling an asteroid is being able to beacon down into and out of the optimal Kerbol-Karborundum orbit for "free" with the right setup! Also the suggested +GMU 6m/s2 for LB-10 puts a ship at 180,100km above Kerbol, above the 150,000km optimal orbit. Makes getting a beacon there to begin with a nice career goal. Not game breaking - keeping the LB-10 under 1400C is difficult and will probably involve an asteroid anyway (imagining an ESLD contract pack right now that says put LB-10 into this tiny, tiny solar orbit with minimal deviation. Keep it there for 1 day. BOOM! Overheat before time is up ) Runner up is a 1.25r orbit around Eve (10.67m/s2).

• a Kerbin asteroid can save up to ~750m/s under the existing setup but from a gameplay perspective it's not much by the time the tech is unlocked and K+ is harvestable - i.e. 12,000m/s return from Eve or 8000m/s Low Eve Orbit. Maybe an added benefit could be a reduction in EC for initiation & standby (+/- transfer EC)? Based on the gravity "logic" an asteroided beacon would use less EC than an un-asteroided beacon at the same altitude. Would need EC curves rebalanced from initial min altitude to 1.25r so that it EC cost rapidly catches up and overtakes un-asteroided cost. (Haven't played with this bit yet, so perhaps it's already a feature).
  
• thinking about it, this becomes a big deal in the outer planets as lower EC cost-same altitude helps with EC generation issues; the deltaV to move stuff at that distance is actually really decent so hauling asteroids as an EC solution becomes a viable gameplay option.
  
• 10 long strutparts with 30 Gigantors will power that beacon on an asteroid around Eve a number of posts back.
  
• we laugh in the face of high initializing EC costs (see sat pic below)
  

80 ton pipe dream pics to spice up your thread. Pretty sure 4000 units of K+ from 2 hours around Kerbol can send it with velocity alignment to Jool/Sarnus-Eeloo/Neidon/Plock to top up some beacons and back to Kerbol for moar K+. Now to make it happen in career mode at some point.

Javascript is disabled. View full album

Edited July 9, 2015 by Weywot8

[Aerosfilis]

I'm glad this mod is now up to date!

It is one of my favorite mod. Way more interesting than basic Jump Drive as you can't directly jump where you want (unless you use the IB-1).

Let's install that rigth away

[TMarkos]

snipped

First off, thank you very much for taking the time to give such well-thought-out feedback. It’s often hard to assess something you wrote yourself, so having someone else’s view on it is much appreciated.

I’m currently doing a career mode playthrough with OPM as well, it’s exactly this sort of use case that caused me to create the mod. OPM’s inclusion of Eeloo in a planetary system combined with it being one of the few sources of Karborundum also makes for interesting gameplay, and I’m excited to take the playthrough to that point. I’m glad to hear it’s playing nicely with OPM, I didn’t anticipate any errors since there are no hardcoded body references in the mod but it’s good to know that it’s working nevertheless.

I’ve created an issue to investigate your comment about the minimum altitude not precisely matching, but I’m going to guess it has something to do with the display altitude being calculated directly from celestial body mass and distance values whereas the beacon operates based off of the directly sensed gravitational pull at the vessel’s location. The slight discrepancy between what gravity should be at a given location and what it actually is based on the vessel’s sensors is going to be hard to nail down, but I will attempt to see if more accuracy is possible.

For formulae, I’m going to paste the calculations from the code directly, please feel free to reply back if I’ve failed to explain a variable. Full source is here: https://github.com/TMarkos/ESLDBeacons/blob/master/Source

Input variables are:

• Trip distance, in meters.
  
• Tonnage, as displayed in KSP.
  
• Beacon Model, LB10, LB15, etc.
  

Here they are in traditional format:

T for tonnage, d for distance, K for the distance from Kerbin to Kerbol, and p is a penalty only applied after 1GM for the small beacon because I couldn't get it to curve right without it.

private double getTripBaseCost(double tripdist, double tonnage, string nbModel)
{
double yardstick = Math.Sqrt(Math.Sqrt(13599840256));
switch (nbModel)
{
case "LB10":
double distpenalty = 0;
if (tripdist > 1000000000) distpenalty = 2;
return ((Math.Pow(tonnage, 1 + (.001 * tonnage) + distpenalty) / 10) * ((Math.Sqrt(Math.Sqrt(tripdist * (tripdist / 5E6)))) / yardstick) / tonnage * 10000) * tonnage / 2000;
case "LB15":
return (700 + (Math.Pow(tonnage, 1 + (.0002 * Math.Pow(tonnage, 2))) / 10) * ((Math.Sqrt(Math.Sqrt(tripdist * (tripdist / 5E10)))) / yardstick) / tonnage * 10000) * tonnage / 2000;
case "LB100":
return (500 + (Math.Pow(tonnage, 1 + (.00025 * tonnage)) / 20) * ((Math.Sqrt(Math.Sqrt(Math.Sqrt(tripdist * 25000)))) / Math.Sqrt(yardstick)) / tonnage * 10000) * tonnage / 2000;
case "IB1":
return ((((Math.Pow(tonnage, 1 + (tonnage / 6000)) * 0.9) / 10) * ((Math.Sqrt(Math.Sqrt(tripdist + 2E11))) / yardstick) / tonnage * 10000) * tonnage / 2000);
default:
return 1000;
}
}

 // Calculate base cost in units of Karborundum before penalties for a transfer.

This basically just operates off the difference in real universal velocity between the two endpoints as well as the tonnage of the vessel being transferred. Remember that the two vessels in question are the beacon vessels, not the transfer vessel, so if there's an offset between the transferring vessel and the origin beacon the origin beacon's data is used.

private double getAMUCost(Vessel near, Vessel far, double tton, string model)
{
Vector3d velDiff = getJumpOffset(near, far, model) - far.orbit.vel;
double comp = velDiff.magnitude;
return Math.Round(((comp * tton) / Math.Pow(Math.Log10(comp * tton),2)) / 2) / 100;
}

// Calculate AMU cost in units of Karborundum given two vessel endpoints and the tonnage of the transferring vessel.

Your description of EC use is more or less in line with how the mod operates currently. The major discrepancy is that there is no EC draw on vessel transfer, which is a choice I made based on the fact that the beacon is invariably unloaded and put on rails immediately following activation. Since the vessel cannot generate or spend EC while on rails, the practical result of on-transfer costs would be that the user would be stuck waiting for a beacon to recharge every time they approached it for transit, which is undesirable from a gameplay perspective.

Further discrepancies include that I’ve based the activation charge on, among other things, the amount of Karborundum on the vessel. I wanted to scale the cost with the planned use, so if the player has decided to transfer a small probe the beacon transferring it should be appropriately scaled. If the player is building a transit hub for ferrying massive freighters of mined goods, then they will need more fuel and therefore more EC to maintain the beacon. Clever engineering and logistics can be used to keep the onboard fuel supply at a minimum and reduce the costs for both activation and constant operation, which I view as a positive – problems should be solvable with clever engineering. However, large transfers necessitate incurring that cost for some period of time because the entire used amount of fuel has to be aboard at some point for the reaction to occur. The capacitors from NF Electric would be a good fit, I think.

I will have to do some balance testing as you suggested, given the increased output of solar panels near the sun. However, I've also heard indications that solar power does not work well when the panels heat up, so there may be a hard limit on how well that works. The high end of the exponential increase in energy draw is VERY high, so I'm not too worried about it being "too easy" to grab constant power. Decreasing the gravitational tolerance as you've suggested is also worth considering, as it would have the effect of dramatically increasing EC costs within a gravity well.

I’m not sure how much you’ve played with the GMU and high-mass stations, but the gist of it is that the GMU is generally not worth using unless you’re using it along with a significant mass to operate inside of a gravity well. The cost of running a beacon at any given gravitational field strength is always more with a GMU than without, although the difference is proportional so it’s unlikely to be backbreaking at far-reaching orbits. Where the GMU really starts to dial up the difficulty is if you’re using it very, very close to a large gravity source like Eve or Jool. In my testing, having a GMU-enabled LB-10 very close to Eve resulted in five-digit activation costs and three-digits of EC consumption per second with modest fuel on board. It’s not unachievable, but it does require planning to ensure the operational costs are taken care of. Granted, considering you need at least a Class-E asteroid to get that close and asteroids don’t spawn naturally in any of the systems that you’d be likely to use them in, the engineering challenge involved is not particularly difficult relative to moving the station there in the first place.

Your theoretical Kerbol free-transfer beacon is interesting, but there are some technical challenges you may not have considered. First, the LB-10 is the easiest to get online in that situation but LB-10s are basically useless in solar orbit due to their effective 1Gm transfer limit. You’d need at least an LB-15, so I’ll use that as my example. The GMU mass offset increases the operational range less effectively for the larger beacons proportional to their decreased gravitational tolerance – the LB-10 has a base limit of 1m/s^2, the LB-15 is at 0.5m/s^2 and the LB-100/IB-1 at 0.1m/s^2. This means that you need (roughly, not exactly) twice the mass to achieve the same operational altitude for an LB-15 vs an LB-10, and 10x the mass for the large beacons. The formula for gravitational acceleration at a given radius is g = GM/r^2, where g is the acceleration, G is the gravitational constant, M is the mass of the main body and r is the radius from the center of the body.

The normal solar operating limit for a LB-15 occurs at around 4.6Gm, right outside the closest approach Moho makes. By contrast, the acceleration from gravity at 150Mm is a crushing 6.92m/s^2. To counteract this using the GMU, you would need to have a total vessel mass of around 3700 tons (1 particularly large class-E asteroid or two small ones) and your per-second electrical charge usage would be a little north of 275 EC for 100 K+ on board, increasing by ~3 EC per additional unit of K+ present. Onlining the beacon would take a whopping 20,757 units of EC at 100 fuel, or ~207 per unit of fuel. None of these challenges are insurmountable with clever engineering, but considering the fact that you’d have to get those class-E’s into low solar orbit using traditional methods and the challenge of heat management at those altitudes, I think you’ll agree that the logistics of keeping such a harvesting station running are decidedly nontrivial.

A good compromise solution would be to have the periapsis of the orbit be as close to the sun as the harvester could survive, but have the apoapsis be within a less strenuous gravity region. The station would then have windows during which it harvested followed by a window where transfer away from the station would be more economical. The collection rate would be a fraction of what it otherwise would be, but fuel would accrue nevertheless. Heat management would also be simplified due to the breaks in between close approaches allowing for a return to relatively normal values rather than having to deal with the close-in heat constantly. I’ve had people tell me that most ships are pretty much eventually going to explode if they stay under 190Mm, it’s just a matter of when.

I'd like to explore sort of the worst case scenario for logistics transport for the "highest throughput" harvester setup. Let us say you manage to resolve all of the aforementioned problems of heat, electricity and asteroid relocation. Your pictured 80-ton harvester manages to fill up with 4000 K+ from its turn around Kerbol and you’d like to top up your Jool beacons. Your solar orbit will allow you to easily pick the shortest distance to Jool, which assuming you’re at around 200Mm would be (best case) 65.13Gm disregarding the minimal inclination of Jool’s orbit. We’ll use 65 on the nose for easier math.

The first debit you face is the base transfer cost. Assuming an 80-ton wet weight (including your shiny new K+) your transfer cost would be a rather economical 80.19 K+ using the IB-1, but since we’re deep in the gravity well any operating beacon has to be hooked into a massive asteroid. This forces you to use a separate ship with a beacon like the LB-100 Longbow (cost: 114.14 K+), but the Longbow can’t realistically be onlined that close to the sun. I’m not going to do napkin math for it, but you’re looking at a total required vessel weight of something like 15000 tons and 1500 EC being consumed every second.

So we back off to the LB-15 that we’ve already established can be made to work at those altitudes. Unfortunately, the LB-15 cannot handle high vessel weights very well and the cost for transfer will be a rather steep 1071.2 units. Fortunately this is debited from the beacon vessel rather than the transferring vessel, so we may safely disregard it except to note that it will increase the processing time before the next trip is ready.

However, you’re also taking advantage of the AMU’s velocity matching ability, so you’re also going to have to shell out for that. Now, let’s consider your orbital speed. In the unlikely event you’re entering into a circular orbit at 150Mm, you will have somehow achieved an orbital velocity of around 95830m/s. That seems high to me, but I checked it a few different ways and the same math returns correct orbital velocities for the planets, so I think it’s accurate. Not only that, you will have dragged about 3700 tons of asteroid with you. So, accepting this unlikely premise, you will have to have the AMU cancel out around 91km/s of that speed to match Jool at its fastest, a service for which it will charge somewhere in the neighborhood of 775 K+ for an 80 ton vessel. This is quite the bargain, as the energy matching is roughly equivalent to suddenly stopping a fleet of 75 Airbus A380s at cruising speed.

Next we must consider the Heisenkerb Compensator. This is the handy widget that keeps everything from exploding during transit, including your hard-won Karborundum, crew, and any other less-than-stable resources you may have on board including (but not limited to) nuclear fuel. The HCU takes a toll of 0.1M/0.0058 units of K+ for M = mass of protected resources. Assuming the only protected resource on board is your still-untouched 4000 units of Karborundum, this works out to an entirely non-coincidental 10%, or 400 units. This is again debited from the transferring beacon.

Tallying up, we arrive at a total cost of 2246.2 K+ in total. This poses two rather significant problems – first, you have to consider the return trip. Even with the cheaper return due to offloading the KBD (ship mass = 56.8T) and therefore obviating the need for a compensator, you’re still forced to use a similarly massive LB-15 rig and AMU to make the return with an approximate cost of 184 base + 570 AMU = 754. The vast discrepancy in base cost is mostly due to the fact that the LB-15 cutoff for weight kicks in around 40 tons, so the closer you are to that the better the cost gets.

The far more serious problem, however, is that it is likely flat-out impossible to run an LB-15 at that altitude (acc due to gravity = 6.92 m/s^2) around Kerbol with 2246.2K+ on board due to the electrical charge requirement of approximately 466,190 EC to turn on the beacon and, even with clever fuel transfer circumventing that cost, 6216 EC per second to keep it active. Even if you were to transfer the vessel without the AMU online, the required fuel would still have you pulling 4072 EC/s for beacon operations.

So we abandon the plan of a direct transfer and instead decide to do it in stages – an LB-10 at the harvester, a Longbow in a wider resonant orbit so that it comes within 1Gm of the LB-10 every n orbits, and suddenly the extreme numbers calm down a bit. However, this does pose a problem of efficiency, since now the meatier of the two transfers (that being the hop out to Jool and back) must be paid for out of your 4000 units of cargo, drastically decreasing your payload delivered per trip. The Heisenkerb toll doubles, and the AMU is forced to cancel out some slight additional incurred velocity.

Then include the return trip.

Then remember that we’re just talking about Jool, not the OPM planets.

I would estimate that the most efficient configuration for a Joolian transfer is probably a compromise sundiver orbit like I proposed a few paragraphs back, with an orbital period resonant with Jool and timed such that once every n orbits, the station is at aphelion when Jool is closest to it in orbit. This allows for a direct LB-100 transfer with no asteroid GMU trickery. The only truly difficult part is that higher apoapses mean shorter times spent in the harvest belt, so you have to find the equilibrium where you’re in the harvest belt for enough time to grab sufficient KBD but at aphelion at a sufficient distance that beacon orbital speed and gravitational acceleration allow an efficient Joolian transfer. The word of the day is, once again, nontrivial.

I won’t continue to explore the permutations of this, but I hope I’ve succeeded in conveying some of the additional complexity involved in the idea of a “free†transfer from a low-orbit harvester station. There are certainly workable, efficient ways to export K+ from low Kerbol orbit, but they require thought, careful planning and a heck of a lot of infrastructure investment before they become workable – which is sort of the point. With absolutely perfect conditions I would estimate you could probably preserve 85% of the initial Karborundum on a Kerbol-Jool transfer.

As for your ship, that's quite the beast! I really have to try and design a solar harvester at some point during my career playthrough now that the solar K+ is unlocked, although my short-term plan is to mine out dresteroids. Eve seems tedious, and I only want to send a ship to Eeloo once - that ship being a beacon with already-harvested Karborundum on board that I can use to send everyone else.

@Aerosfilis - Glad to hear it! Come back and post a picture of your beacon setup once you've had the chance to play around with it.

[Weywot8]

Many thanks! Will take sometime to digest the info provided.

Skimmed your ramblings about solar harvesters - very good points. Was fooling around in Sandbox after my last post to really figure things out and came to similar conclusions. Documented in pics below.

Javascript is disabled. View full album

Minor issue while fiddling around - sometimes it doesn't warp after I confirm. Usually happens after I timewarp to get the red orbit indicator lined up.

Also, is it possible to put an arrowhead/orbital indicators on the red line to show which direction the ship moves relative to the beacon after warping in? That improvement would be really helpful when AMU isn't used.

I like the destroids approach but got rather obsessed with with min-maxing time-Karborundum production along the way + tendency to put big infrastructure into orbit/on planets. Last biggie project before restarting on 1.03+OPM was landing a "fuelspike" (24drills+IRSU+lotsa batteries and solar support+MKS logistic hub) at the best spots on Mun, Minimus, Duna and Ike.

[TMarkos]

Minor issue while fiddling around - sometimes it doesn't warp after I confirm. Usually happens after I timewarp to get the red orbit indicator lined up.

Also, is it possible to put an arrowhead/orbital indicators on the red line to show which direction the ship moves relative to the beacon after warping in? That improvement would be really helpful when AMU isn't used.

The failure to warp may happen if you've time warped enough that the jump parameters are no longer valid, but it should be popping up an error message in those instances. I'll investigate and see if I can duplicate it.

There is actually a directional indicator, but I'm having issues getting it to scale correctly in solar orbit. If you try a jump within the kerbin SoI you should be able to see it clearly.

Your mission is impressive! As I was typing out my response the other day I worried that perhaps the more available Karborundum band would be too easy to exploit, but looking at the heat mitigation you had to throw on there I think we may be at a fairly appropriate difficulty level.

[TMarkos]

Minor update on Github - no release or anything, but I've resolved the conflict with AntennaRange by changing how the Hailer determines if it's active, as well as the orbital direction indicator scaling. The scaling isn't perfect, but you can at least see it in solar orbit now.

Also, the spread values for how close a transfer lands to a beacon are rebalanced, and the confirmation window will throw a warning if your potential arrival zone is too close to a planetary body or its atmosphere. You can still jump, but whatever happens after that is not covered by insurance.

[Weywot8]

Thanks for the fixes! Been staring at plots of the Karborundum costs for a long while and came away with the feeling that the curves are hand crafted? (tried to be cheeky with some calculus for potential min-maxing). Missed a few brackets on the traditional format but figured it out from the code.

Hadn't realised the limitations of on-rails ship control in KSP. Guess that warping instantly leaves the beacon on rails so it can't be referenced to do something like the life support mods - record EC remaining, EC production/consumption, time of last update. Then when the next ship comes in physics range, the beacon gets updated from calculations based on current time vs. time of last update? (Inferred that's what life support mods do while browsing the sfs on a different issue, could be wrong) Current mechanics has it's own logic too so no complaints here.

[TMarkos]

Thanks for the fixes! Been staring at plots of the Karborundum costs for a long while and came away with the feeling that the curves are hand crafted? (tried to be cheeky with some calculus for potential min-maxing). Missed a few brackets on the traditional format but figured it out from the code.

Hadn't realised the limitations of on-rails ship control in KSP. Guess that warping instantly leaves the beacon on rails so it can't be referenced to do something like the life support mods - record EC remaining, EC production/consumption, time of last update. Then when the next ship comes in physics range, the beacon gets updated from calculations based on current time vs. time of last update? (Inferred that's what life support mods do while browsing the sfs on a different issue, could be wrong) Current mechanics has it's own logic too so no complaints here.

There were definite numbers in mind for each beacon, yes. The difference in the formulae rises from the unit of the end product - initially Karborundum was purchaseable and the cost was supposed to be equivalent to a similarly featured rocket. Now that it is harder to get, the numbers are slightly different and I had forgotten about the adjustment.

A system like what you describe is certainly possible for decrease in resources over time but it is much less doable for something like electric charge where the variables are not just time but also solar exposure and intensity as well as variable draw resulting from the beacons which also traces back to variable gravitational field strength.

[Weywot8]

Hadn't realised that, thought some nifty algorithm/good enough heuristic & rate of change measurement was incorporated in the life support mods for EC. Guess I'm only switching away from space stations while they are in the sun!

[ironhawx]

How do I mine the mineral? when scanned kerbin and mun there was none, and even in sandbox i can't fill the holding tanks for it, so have yet to be able to use this mod and so want to play with it.

[TMarkos]

How do I mine the mineral? when scanned kerbin and mun there was none, and even in sandbox i can't fill the holding tanks for it, so have yet to be able to use this mod and so want to play with it.

Three ways to get it - surface of Eve, surface of Eeloo, and asteroids. If that sounds daunting there are configs in the download from kerbalstuff.com (extras folder) that also make it appear on Tylo, Dres and/or Ike.

[hipy]

Is there a way to fill the tanks withouth mining astroids? I plan on using it in sandbox mode so it would be great if I could just fill up the tank

[TMarkos]

Is there a way to fill the tanks withouth mining astroids? I plan on using it in sandbox mode so it would be great if I could just fill up the tank

Yeah, there should also be a config in that folder that just makes it tweakable in the Vab.

[innomin8]

Any chance you can move the required resource into the configuration files? That would make the mod re-usable with anyone who wants to replace the resource chain (such as making it use a different kind of resource) without needing to re-release the DLLs.

Thanks

[TMarkos]

Any chance you can move the required resource into the configuration files? That would make the mod re-usable with anyone who wants to replace the resource chain (such as making it use a different kind of resource) without needing to re-release the DLLs.

Thanks

Hrm, I didn't code it with that in mind and I'd have to go through and change a lot of hardcoded references to make it work. I don't think it's something I'm going to prioritize as I haven't heard many people aside from yourself asking for greater resource flexibility in terms of which fuel the beacons use. You're free to fork and recompile the DLLs, of course, and I will keep it in mind for the longer term.

[Stoney3K]

Alternatively, you could make a resource converter that makes your beacon fuel out of Karborundum, Karbonite, Ore, LF+O or any other fuel you would want to throw at it, at the expense of quite a bit of ElectricCharge. ModuleResourceConverter is your friend here.

I hate to be restricted to mining a specific celestial body just to be able to use the beacons in sandbox, or having them only available in the end-game in science/career mode (using them more early on would be possible but ridiculously expensive).