TMarkos

Hello! I've made some small changes to the documentation that may help people out. A page outlining how electrical charge usage works is here: https://github.com/TMarkos/ESLDBeacons/wiki/Electric-Charge,-Beacons-and-You I've also corrected the gravitational chart diagram, since I accidentally used units of g rather than m/s^2. Assuming Witcher 3 doesn't eat all my time I'm hoping to tackle temperature and transit cost balancing next. Many of the parts were created before temperature was a thing, so they're unrealistically robust in that regard. Insofar as transit costs go, if anyone has managed to get a functioning network up I'd be interested to see screenshots of your cost breakdown window to give me a few real-world examples of usage I can use as data points.

Well, it'll certainly assist with getting Karborundum off Eve if you go that route. Some nice ducted fans and OP engines you can use for that purpose.

Might have been unclear - you don't actually need Karb and K+ to use this. If you have them, it'll use those drills and tanks just fine. If you're running ESLD standalone, however, you'll have the option to pull Karborundum using the standard drill.

The thought did occur to me, but I decided to leave it with Karborundum for the simple reason that it isn't just a matter of timewarping. There are only three locations you can stock up on this stuff, and they each present unique challenges. You can rather easily and quickly get it from asteroids, but only some asteroids have it and you don't know if it does or not until you reach there, so it's kind of like a double-or-nothing. Eve has its obvious drawbacks, but you don't have to worry about landing your refinery (so it can be bigger) and power generation is simple. Eeloo is just really, really far away, which means that your initial setup will take years and you have serious problems with power generation (I think you need 3 jumbo solar panels to provide 1 EC/s) so you either have to blitz RTGs, also refine ore for fuel cells, or come up with some other creative solution. There's a potential 4th solution if you're running K+, which involves a solar-orbit particle collector. That just sounds like a huge pain in the ass, but could be fun. Still difficult, so I like it. Contrast that with ore, where you could just do the standard thing where you plop a refinery on Minmus and go to town. Nobody would bother with the technical challenges of siting it elsewhere. This makes you really problem-solve to get your infrastructure up, so that when you warp that first vessel you feel like you're really earning it. CRP isn't a crippling dependency, it's more just an easy sheet of resources you can include. Besides, it's Roverdude's stuff - it's pretty much as close to stock as you're going to get.

Okay! Career is workable now. Kerbalstuff has been added back in as a source. Parts are now properly around the same nodes you can start extracting fuel, and the more advanced beacons are one node further. It should gracefully remove its changes to the stock resource extraction if you happen to have K+ installed. https://github.com/TMarkos/ESLDBeacons/releases/tag/0.4 Changelog 2015-05-17 0.4 - Placed all parts in Adv. Science Tech and Experimental Science nodes. - Balanced part costs & part entry costs. - Added MM config (Scan_Extract_MM.cfg) to add Karborundum scanning to stock resource extraction parts in the absence of K+. Karborundum now appears as specified in CRP on Eve, Eeloo and in some asteroids. - Added manufacturer to techboxes. - Added nickname to IB-1. - Updated list of resources that need Heisenkerb shielding to avoid exploding during beacon transit.

So I've been away for a bit, but I think I'm going to crack this open now that we're in 1.0.2 and I have some free time here and there. I've taken an initial stab at fixing the part issues that came up. I'm keeping this github-only until I've finished the career-mode rebalance. Any input from interested testers is always appreciated, since I'm sure I missed a few bugs here or there. Just for emphasis - this is really not intended for career-mode use in its current state. You will have a bad time getting Karborundum (unless you're using RoverDude's K+) since there's no way to procure it outside of the VAB/Hyperedit right now. I'm just getting the mechanics ironed out so I can take a look at the new stock resources system. https://github.com/TMarkos/ESLDBeacons/releases Changelog: 2015-05-17 0.3g -Updated part nodes/sizes/attach. -Recompiled against 1.0.2. -Updated ModuleManager version. -Updated Community Resource Pack files.

Yes! Not today, but as I have time. The day after I made the post that nightingale quoted (the one where I said I'd have time to work on it that week) a coworker went on short term medical leave and I inherited a rather major project. Hopefully I can stop back in and keep things tidy (I plan to at least find some time to confirm it's compatible with the current version and update the CRP resources again) and when things clear up I'm going to tackle my open issues list again.

Are you using any of the assistive boxes to match velocity? Those can add a bit. Same goes for if your ship has a lot of Karborundum on board and you're using a Heisenkerb Compensator - it'll charge extra if "volatile materials" are on board.30t should be well within range for a Kerbin-Duna trip on the LB15. LB15's strength is in vehicles under 40t or so, so yours shouldn't pose a challenge.

I'm currently just checking to see if Karbonite and KarbPlus are there to adjust the tweakability of Karborundum (it's not tweakable if Karbonite is present) and to adjust the availability of the Karbonite -> Karborundum converter (not available if K+ is present). The config uses the standard USI converter in the Karbonite -> Karborundum conversion for those that don't want to harvest with K+, but I plan on opening that up again to incorporate the microgravity limitations and secondary resource requirements that had been discussed previously. Even then, I don't think there's much of a risk of stuff breaking. Worst case scenario I have to update my MM configs. I'm not using anything in my own modules that would result in a dependency on USI stuff.

Released 0.3b - mostly just a compatibility update, but I wanted to fix that before I dive back in. I probably should have put it out there earlier that my job (actual pays-me-money type job) can get pretty crazy and so you may occasionally see me disappear from the face of the earth for a few weeks. Please don't interpret this as me abandoning the mod! I should have some free time this week and the next and I plan to use it to chip away at the remaining pre-release issues. Download Dropbox Kerbal Stuff Github Changelog 2014-09-21 0.3b -Updated ModuleManager config for Karbonite Plus compatibility. -Updated ModuleManager version. -Updated Community Resource Pack files. Well, that's a bit more difficult than it sounds at first glance. See, the maximum charge required to turn on and operate the beacon is tied to how deep it is in the gravity well relative to its maximum gravitational tolerance. If you find that a beacon isn't capable of going online in its current position, move it farther out and see how that affects it. Also, be careful if you have a Gravitational Mitigator installed, as it will increase the electrical charge required to operate at any altitude.

I don't anticipate any breaking changes. At worst, you'll have new models for the surface-attachable parts that are likely going to be a bit bulkier, but I've been taking pains to keep part names the same so it doesn't delete crafts. I already balanced Karborundum usage amounts, so I won't have another reason to change fuel costs. Although you always have to allow for unplanned things to intrude, if nothing unexpected arises there should be no major break in functionality between now and release.

Adjacent to the beacon, yes - there's a device called the Alignment Matrix that lets you cancel the velocity vectors (more or less) at the cost of a LOT of Karborundum. I thought you meant anywhere within an orbital band in the target system SOI.

That sounds feasible. Have to muck around with balance issues to settle on something that works and isn't tedious, but I'll try a few combos of resources and see what emerges. I think that the logistics flow of refilling these beacons will develop more depth over time, as harvesting isn't currently available and we're still debating the best implementation of conversion. I don't think I'll be integrating antimatter, since that would require a dependency on KSPI. There are parts that modify efficiency - the Superconducting Coil Array reduces base jump cost, and your selection of beacon will modify both the jump cost and the precision of your arrival. Your idea for the WOOPS would be tougher to balance out, since right now interplanetary transfers involve use of the destination beacon to offset differences in orbital velocities. I suppose I could introduce the option for interplanetary beacons to transmit in local mode like the smaller beacon sizes and widen the targeting area dramatically, but I can't see a system where the area of emergence isn't centered around the beacon - that's a bit too much like Hyperedit for my taste. I do intend to look at adding sounds, but visual effects are going to take a backseat to keeping the transition smooth and lag-free. If I can make a visual effect work without affecting any part of that, then it may be in the mod in a post-RC phase.

Well, K+ just adds parts to deal with the pre-existing Karborundum maps that RoverDude included in CRP the other day. Technically, you could harvest Karborundum in any game that had the Community Resource Pack installed, as long as you had a part to harvest it with. That makes detection a bit more difficult, hence nontweakable being the default state - it's defined in the CRP along with the maps for harvesting it.

Yeah, I think I'm making some errors of phrasing. When I say "FTT" I really mean "K+" as I was thinking of K+ as being basically "FTT Phase 2". I should probably stop thinking of it as part and parcel. Here is my current MM config. Hopefully this clears up what I'm trying to do. Obviously the "FTT" reference in here is a placeholder and will be changed to whatever your dummy DLL is called. @PART[KA_Distiller_125_01]:NEEDS[Karbonite,!FTT] { MODULE { name = USI_Converter converterName = Karborundum conversionRate = 1 inputResources = ElectricCharge, 4, Karbonite, 2 outputResources = Karborundum,0.0016,False } } @PART[KA_Distiller_250_01]:NEEDS[Karbonite,!FTT] { MODULE { name = USI_Converter converterName = Karborundum conversionRate = 1 inputResources = ElectricCharge, 3.6, Karbonite, 2 outputResources = Karborundum,0.0016,False } } @RESOURCE_DEFINITION[Karborundum]:NEEDS[!Karbonite] { @isTweakable = true } That means Karbonite disables tweakability, and the ability to extract Karborundum disables the ability to convert Karborundum. For the converter, I would love an option for the USI standard converter that is basically a variable which allows you to define how efficient/wasteful the process is. Set it to 0, then all inputs are converted to outputs. Set it to .99, and the process consumes 100% of inputs while only producing 1% of outputs. I think this will prove to be more generally useful for the converter class as a whole than a dedicated microgravity sensor, the implementation of which is trivial given a prebuilt efficiency modifier in the converter.

I intend to fully support standalone, Karbonite-only and FTT players as distinct modes of operation. I think flexibility is a good quality in a mod, since it doesn't lock players into a certain configuration to use the mod's capabilities. I originally developed this as a reaction to MKS/OKS and the need to send repeated missions over a long period of time to a single location, and I think that need resurfaces independently of which resource mods you have installed.

Well, a thought that I had afterwards was that the conversion shouldn't be unavailable in a gravity field, just really inefficient - so that the ideal would really be to mine it someplace like Minmus and then pop it out to high orbit for conversion. That takes care of the issues of on-ground conversion (no longer economical) and atmo-skimming conversion (doable, but now stupidly time-inefficient compared to the other way). @Scottpaladin - the MM config will detect FTT and disable the distiller modification if it's installed.

You have a point there. The microgravity conversion solution would be fun, but at that point I'd probably have to look at coding my own converter, or at least a class that modifies the converter - the standard USI Converter that Karbonite parts use doesn't have the capability to filter on gravity. I'll open an issue to look at the possibility, since it's pretty silly to leave that workaround there - they should either both be tweakable, or conversion should be harder. The KBD tanks are relatively similar in rank to the beacons in terms on when you unlock them, but they're in different branches. The tanks are all bound to the materials research nodes, while the beacons are under electrics. EDIT: RoverDude, didn't see you there. Those look awesome! How much does the biggest hold?

I've got my phone set to ping me when I'm back from work so I can merge it in and upload a new release. I've been including just the CommonResources file and not the other components, will I run into any issues doing that?

When you have Karbonite, the Karborundum is not tweakable. That means it won't show in the VAB, but will show once launched. Pigbear: The cfg for Karborundum resides in the Community Resource Pack folder in the CommonResources.cfg file. Make sure you have an up to date version of that file, as there were a few recent versions without it included. Roverdude: That looks incredible!

Trust me, the axis swapping is necessary in all cases. I couldn't find a situation where it was helpful not to do it. It only applies to values derived from or input to the Orbit class, though - you'll note that I could skip the coordinate swapping for far.transform.position, but not for exitTraj (which is derived from several Vessel and Celestialbody orbit.vel values). The line is actually a triangular marker that serves to indicate the direction of travel along the orbit I'm projecting. The resulting drawing looks like this: https://i.imgur.com/QRNsyEs.png I'm offsetting the marker so it doesn't overlap the icon for the ship I'm using as the origin point.

Fixed it up! Here's the solution, so it's documented if anyone finds this while googling. The LineRenderer needs useWorldSpace = false. The parent transform of the LR object was set to the matching ScaledSpace tranform (in ScaledSpace.Instance.scaledSpaceTransforms) rather than the MapObject. Not sure how necessary this was, but it's working fine. The transform position for the LR was set to the scaled conversion of the origin target's position, using .position rather than .localPosition. The exit vector was run through .xzy to correct the z/y swap. Here's the final working snippet: // Directional indicator. oDirObj = new GameObject("Indicator"); oDirObj.layer = 10; // Map layer! oDirection = oDirObj.AddComponent<LineRenderer>(); oDirection.useWorldSpace = false; oOrigin = null; // oOrigin is a Transform. foreach (Transform sstr in ScaledSpace.Instance.scaledSpaceTransforms) { if (sstr.name == far.mainBody.name) // far is a Vessel. { oOrigin = sstr; break; } } oDirection.transform.parent = oOrigin; oDirection.transform.position = ScaledSpace.LocalToScaledSpace(far.transform.position); oDirection.material = new Material(Shader.Find("Particles/Additive")); oDirection.SetColors(Color.clear, Color.red); oDirection.SetWidth(20.0f, 0.01f); oDirection.SetVertexCount(2); oDirection.SetPosition(0, Vector3d.zero + exitTraj.xzy.normalized * 10); // exitTraj is a Vector3d. oDirection.SetPosition(1, exitTraj.xzy.normalized * 50); oDirection.enabled = true;

0.3a up! Only one new feature in, but I'll be glad to have it done with. It took me forever to figure out how to accurately display direction. Changelog 2014-09-01 0.3a -Directional indicators for orbit projections. Download Dropbox Kerbal Stuff

Due to the cost of Karborundum, the beacons and fuel tanks are empty by default. If you don't have Karbonite, you can tweak the fuel in the VAB and pay for as much as you feel you need. If you do have Karbonite, you should refine it using the distillers.

Done with the retexture, so here's 0.3! New beacon models for everything. Folder structure change with this one, so make sure you delete the old mod folder entirely if you're upgrading. Changelog 2014-09-01 0.3 -New models and textures for large beacons and IB-1 to match the LB-10. -Much lighter memory footprint, better inline fit. -Folder structure change. -Better utilization of shared assets. Download Dropbox Kerbal Stuff