TMarkos

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.

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.

This looks awesome, can't wait to play with it. If I'm running Outer Planets and have a few planets zipping around that aren't in the default game, can I simply modify bodies.ini with their correct orbital parameters or will that screw things up?

These are insanely useful, I especially like the biome overlay map to plan science trips. You don't happen to have a minimum size requirement for a biome to count in these, do you? Looking at the biome and landing guide maps I feel like some of them are taking into account a square meter of space that's Duna Craters (for example) and it'd be functionally impossible to find.

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.

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

Your Surface Scanning Module should have been modified by the Community Resource Pack to give you the composition of any asteroid you're attached to. Claw on to an asteroid and right click the scanner for a percentage breakdown:

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

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.

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.

It's been a while, hasn't it? I'm hoping to get a few more bugs ironed out and a few more features baked in before I push it to release. I've had to leave off work on it for the past couple of weeks because my job started demanding more time again. Once I have a solid block of downtime (hopefully this coming week or the next) I can resume work on it and see how much I can knock out of the issues list.

Probably has something to do with me forcing part activation during the startup sequence. I'll download AR and explore the interaction sometime this weekend, for now I'll log an issue on the tracker. Thanks for bringing it to my attention.

It actually modifies both the camera distance from the ship and the FoV, making it a rather extreme variant of the classic dolly zoom. http://en.wikipedia.org/wiki/Dolly_zoom I played around with making it an actual dolly zoom, but it was too slow and didn't mask the transition as well as momentarily dialing the FoV up to silly levels. Because of that the distance manipulation is less noticeable until the end.

Disregard previous post, 0.6 is up without the described fixes but with another longstanding issue resolved - the lack of beacon visual effects. Pretty pleased with the way this turned out. Let me know if you're experiencing any camera strangeness as a result and I will attempt to remedy.

Another minor release to 0.5g, the IB-1 now has an integrated hailer since it was silly to require an antenna to talk to your own vessel. Relative velocity predictions are now accurate in the confirm window, they were previously just absolute velocity which sort of defeated the purpose. Finally, all in-system transfers obey the rules that previously only applied to the LB-10 - that is, the far beacon's velocity is not taken into account. I like being able to cancel out orbital velocity better by using the far beacon for inter-SoI stuff, but intra-SoI velocity cancellation was silly - you'd warp to a beacon 60km away that had 3m/s of orbital difference and suddenly you're dropping straight to the planet with no orbital velocity at all. This should be more intuitive all around. Probably one more round of cleanup before I release to 0.6 and update Kerbal Stuff, I'm looking at the consequences of accidentally arriving inside a gravity well due to normal displacement as well as a few QoL/intuitiveness fixes like making sure all the predictions and readouts are always updated to what they should be showing.

Minor release to 0.5b, scientist discounts weren't being shown/applied. There's also a wiki page up on crew effects.

Github has been updated to 0.5a. Changes this time around: UI Button has been added. Old antenna context menu method still works to activate, but the button is a handy shortcut. Scientists will now give you a discount if they're onboard an active beacon ship that has an SCU active. The minimum SCU discount is 10%, so depending on the experience levels of your scientists it might not exceed the standard. Engineers on a beacon vessel now reduce all electric charge costs, again dependent on their experience. Pilots on a beacon vessel now reduce penalties for transiting vessels due to drift. For all three crew effects, the maximum reduction in their respective area is 50%. Each star of experience adds roughly 2%, so with 5 5-star scientists you'll get half-off transit costs. Be aware that having less experienced crew onboard (within a given profession) will negatively impact your crack team of 5-star experts. However, if you're short on crew and only have one or two 5-stars lying around, supplementing them with a few extra less-experienced kerbals will still be a net benefit. I decided against putting in transiting vessel bonuses for now, since I thought about it and figured that I'd like to avoid having people design their transiting craft for this mod. I don't want to pressure folks to put extra crew space on all their vessels to schlep along some extra help just for a transit cost savings. By having the crew effects only on the beacon, it limits the design pressures to just that beacon vessel.

I'd say do it, RCS balancing benefits from a wide array of parts to fit individual craft needs. I think a 5-way aerodynamic block designed to sit on the flat side slope of the MK2 fuselage would be fantastic.

I was adding in EKSTRA and ESLD as contract-issuing agencies just now, and I came across something that seemed like it merited a post for others' reference. Squad has the agencies listed with a full-size logo and a scaled logo, with the full-size logo being the standard 256x160 flag and the scaled logo being this wonky 64x40 .truecolor format. Apparently the .truecolor format is just a .png with a different extension, renaming the file allows for editability just like any other .png. This seems to only be used in the VAB/SPH when sorting by manufacturer, so it's in your best interest to have this be the logo on a transparent background. Non-transparent backgrounds will display poorly when not selected, as the game removes all color information and simply displays the transparency mask when a manufacturer tab loses focus.

My theory on this, from my own experiments, is that it has to do with a loss of precision in the transition between rails and unpacked states. I know there's been a lot of adjustment to introduce local frames of reference to do away with floating-point krakens for things far out from the universal origin point, and I believe that when you're unpacked that frame is very local to your current ship. When you pack up the ship while warping on the ground, it maintains that shifted reference frame and takes special care to avoid unpleasant ground-ship interactions. When you are in the orbital frame, though, it doesn't anticipate ground interaction (because, really, who would?) and doesn't take precautions to avoid them. It's using the less precise planetary sphere of reference to describe on-rails orbital vessels, which can cause a slight jump in the ship's position. Not noticeable in orbit, but when you suddenly shift half a centimeter into the ground it's VERY noticeable.

Good idea, it's rolled in. I've also got the asteroid base changes set up, the mass of the ship will now come into play if you're running a GMU. Full changelog and download links are in the OP. Kerbalstuff is updated to 0.5, as is Github.

Hopefully not me! Make sure you pull the release off of Github, it has compressed textures that really cut down the memory usage. @Svm420 - Thanks! I haven't quite nailed down all the particulars (documentation on how to work with some of the new features is pretty slim at the moment) but I'm confident I can puzzle out some interesting game mechanics. @Tutumra - Thanks! Swing by later if you've got comments after playing with it a bit!

From my perspective, contracts serve two major purposes. They are primarily to allow for a player to progress through career mode and obtain funds, but an important secondary objective is to provide incentive to do things that otherwise would not occur to the player. It's a random goal generator to provide meaningful short-term objectives as well as provide a larger sense of progress through things like the planetary exploration contracts. From that perspective, the the contract only has to obey a few rules: The reward should be enough that a reasonable solution can be found which makes the player a profit commensurate with the effort invested and time spent to accomplish the goal. The contract should reward exhibited skill in one or more areas (precision, efficient design, etc). The contract should, where possible, encourage the player to do something they haven't done yet. Repeating the same thing over and over (even in different locations) is grinding and therefore not desirable. I think the best contracts would be ones that have several stages or prerequisites, like the mods that have you launch a station then offer you contracts to expand it. Those are ideal, since now you have progression, incentive and a tangible result of your efforts. Contract packages for remotetech or other infrastructure mods are also nice for the same reason - it's something that expands your gameplay. Unfortunately, stock KSP doesn't offer many infrastructure benefits past having a science lab and having a station to support remote mining.

Not going to throw up a full changelog post, but I've updated a few things and Github now has 0.4b. Mostly it's just new MM configs that support alternate difficulty levels for those that want to jump into the beacons earlier. The difficulty configs optionally make Karborundum extractable on Tylo (still hard-ish), Dres (Easy), Ike (Really easy) or for those that hate mining and logistics there's a config to just let you buy Karborundum in the VAB - albeit not cheaply. I've also compiled a config to support the Community Tech Tree, for those that have it installed. Last but not least, we're on CKAN! The CKAN version is the same as KerbalStuff, so be aware that it has the less-compressed textures, old HCU rate and none of the CTT/difficulty configs. I'll update KS when we hit the next major version, which will be as soon as I've resolved a few outstanding issues. The next major project is tackling Kerbal roles. I'd like there to be interaction with pilots, engineers and scientists when using the system. The concept (not implemented!) so far is: Pilots on the transiting vessel increase transit accuracy and decrease penalties due to distance/drift from origin beacon. Effect scales with rank. No role on beacon vessel. Engineers on the beacon vessel decrease transit costs and decrease overall electric usage of the beacon. Effect scales with rank. No effect on the transiting vessel. Scientists on the beacon vessel allow increase the gravitational tolerance of the beacon, stacking with the GMU. Scientists on the transiting vessel relax the gravitational restrictions the transit path must obey, allowing for closer passes through a gravity well. Effects scale with rank. The idea is that the effects would be relatively small for individuals but that they'd also stack to a fairly high level, giving a strong incentive to build the beacon into a base. I'm also considering providing bonuses for incorporating an asteroid into the beacon vessel, including increased gravitational tolerance or increased accuracy for incoming ships. Curious to hear what people think about both the crew role changes and the asteroid idea. I'd like to add a bonus for people that take the time to make an outpost out of the beacon rather than just tossing a satellite up there.

Okay, campers. I've pushed 0.4a to Github, waiting on Kerbal Stuff until I have a few more things rolled in. The big win is texture compression, the mod is now only a quarter of what it was before in terms of filesize. Also, using the Heisenkerb Compensator is now appropriately expensive again, it was charging about 1/5th of what it should have been. https://github.com/TMarkos/ESLDBeacons/releases/tag/0.4a If you're installing over a previous version of the mod DELETE the old files, or at least the old .tga textures. I'm not sure if KSP loads .dds preferentially now, but you're probably going to have a bad time if you don't clean out the old version. Changelog 2015-05-18 0.4-a - Converted all textures to .dds, mod size dropped from 86mb to 22mb. - Fixed HCU rates for transporting hazardous material, they had lowered with the change to Karborundum density and are now where they should be.