TMarkos

Yeah, I've got the right version of Unity - otherwise I couldn't do emissives! Right now I'm concentrating on getting the parts retextured and compressed so they're not a bajillion mb per part, which is going well. I'll look into schmancy folding antennas afterwards. I still have placeholders for tech boxes and fuel tanks, so I've got to prioritize those.

I tried messing with that, but it doesn't seem to have solved the issue. The lines are, if anything, even more offset than previously. Entirely possible that I'm doing it wrong, though.

Didn't see you there on the bottom of the page! Unfortunately, this mod isn't very interesting in video form. You just sort of navigate through the menu, hit a button and... you're there.

That would be pretty cool. My modeling skills are nearly nonexistent, though. Emissive animations are one thing, but actually changing part geometry is something I haven't tried yet.

I was using 5.

Are you also going to make that absurdly expensive sample module we've talked about? I took a stab at coding a tank that self-decrements the majority of its value once any resources are removed from it, to prevent recovery abuse.

I have placeholder tanks, but nothing fancy. The amount of Karborundum used by the drives is based on tonnage and the distance traveled, as well as the model of drive used. Different drives provide the most efficient transfer depending on how heavy your ship is and how far it's going. Those are the curves for the small, medium and large beacons. 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. The resulting number from those equations can be divided by tonnage and multiplied by 10000 to get the cost per ton in funds for transport. So, with that, the base transfer cost for getting a 40 ton ship over one Kerbin AU (13.6GM) using the medium drive (most efficient for that weight and distance) is almost exactly 40 Karborundum for the base cost, or $80,000 in material worth. Additionally, if you have any of the tech modules on board that will increase. Matching speeds over that distance (let's say an exit vector of about 2.5km/s) would incur a cost from the Alignment Matrix equivalent to: (C*T)/(LOG10(C*T)^2)/200 C for Compensation amount in m/s, T for tonnage. Comes out to an additional 20 units for this example. You actually made me realize just now that I hadn't updated that in the current release, so thanks for that. Furthermore, if the ship is carrying Karborundum, crew, or any other resources that need to be protected by the Heisenkerb Compensator, it will exact a toll equivalent to 2% of the protected items' weight in Karborundum. If this example ship is carrying 500 units of Karborundum and no crew it will take 10 units. So, for this example we're looking at a total trip cost of 70 units of Karborundum, or 140,000 in funds. Keep in mind all this is paid by the origin-side beacon, not the transferring ship - unless it's a ship with the jumpdrive module, in which case it does pay its own way. Local jumps with smaller ships are MUCH cheaper, and you can dodge most of that added cost if you time your jump to avoid huge DV changes and aren't carrying a crapton of KBD. Simply tranferring a 10 ton ship to Minmus from Kerbin with AMU and HCU costs would be closer to 7 units.

I'm trying to render a vector using LineRenderer and I'm running into a snag. I've got this set up: oDirObj = new GameObject("Indicator"); oDirObj.layer = 10; // Map layer! oDirection = oDirObj.AddComponent<LineRenderer>(); Vector3d mapFarPos = ScaledSpace.LocalToScaledSpace(far.orbit.pos.xzy); //far is a Vessel oDirection.useWorldSpace = false; oDirection.transform.parent = farTarget.transform; // farTarget is far's parent body's MapObject oDirection.transform.localPosition = mapFarPos; oDirection.material = new Material(Shader.Find("Particles/Additive")); oDirection.SetColors(Color.green, Color.green); oDirection.SetWidth(2.0f, 2.0f); oDirection.SetVertexCount(2); oDirection.SetPosition(0, mapFarPos); oDirection.SetPosition(1, mapFarPos + exitTraj); // exitTraj is the vector I want to represent. oDirection.enabled = true; It draws the line, and it's close to what it should be, but it's always offset just a little bit and it's skewed in directions it shouldn't be going. That green line in the pictures should be tangent to the red orbit, and it should originate with the outer orbiting satellite on the red orbit. Am I using the wrong references to grab orbital position or something? What could be causing the exit vector to go up like that when every element in this is on the same plane? I'm using the same exitTraj variable to calculate both the red orbit and the green line, and I know the red orbit is accurate. Any help on this would be much appreciated, I've been bashing my head against this particular brick wall for a long time.

That's likely not a mod conflict, that's just sloppiness on my part. I should be able to fix it relatively easily. I'm not sure how to duplicate the conditions that caused the error, though, so it'll be a speculative fix.

. That normally means something in the window code is failing. Was it the first interface window or the confirm screen? Let me know if you identify a mod that's clashing with it.

Ominous like "Made in Evil Kerbal Empire" or like "And that's why we call him 'Radiation Jeb'"? I wasn't really going for the evil look, but I guess it's a bit more (literally, not figuratively) edgy.

Released Dev 0.2c! Beacons now use electricity, both as a large initial requirement and as a constant operational charge. Both amounts are determined by the ratio of the beacon's gravity limit to the current gravity, as well as by the amount of fuel available to the beacon. The GMU now carries a penalty to these charges to compensate for the increased operational range it gives you. The charges are pretty reasonable - you can easily online a fully fueled IB-1 using stock electrical parts - but it requires some forethought and gets much harder to manage if you're using the GMU or are too far out for effective solar use. Also included in this release is the updated LB10 model I posted previously. Dropbox Changelog 2014-08-30 0.2c -Beacons now require ElectricCharge to turn on and to operate. -A large initial charge is required to activate the beacon. -A constant per-second charge is required to keep it operational. -Charge amounts are determined based on the current gravity vs the beacon's gravity limit and the amount of fuel in the beacon. -Using the Gravitational Mitigator now carries a penalty to required activation and operation charges. -Beacons will not start up without at least a small amount of Karborundum aboard. -New model for the LB10 beacon. -Better inline fit -Much lighter filesize - 25% of previous.

Is this working with the established ORS format for harvestable atmospherics, or are you trying to roll your own?

This is true, but my first foray into 3D modeling was pretty much limited to platonic solids and their derivatives. Took a bit of meddling before I could get more creative with mesh geometry.

Okay, I guess I did end up with a new beacon model. Behold the revamped LB10. I'm not going to do a release just for this, but it's on the Github if you want it.

Nope, just EVA fuel. I think you're matching thoughts with RoverDude, though, because he's already sort of got the extended EVA thing going on here: https://i.imgur.com/4m4JcWO.png

No update today, I think - I'm butting my head up against trying to make new parts, and I'm discovering it doesn't come as easily as it should when you're actually trying to make reasonably-sized texture files. The redone LB-10 fits nicely and looks okay, but I'm still not quite where I want to be. Good news is, the filesize is much better. The original LB10 model with its bloated textures was around 23mb, the new one is under 5mb. I'll keep optimizing the UV maps and twiddling with the textures until it's where it needs to be. I guess this is where I put out the invitation to any interested modelers. I can texture things well enough, but I'm total crap at meshes. If someone wants to swoop in like Errol Flynn and save me from Blender, I wouldn't exactly object.

That's actually a thing already - Universal Storage's KAS pack has little EVA Fuel backpacks.

You know, while you're still in concept mode, I've got one word: backpacks. How cool would it be to have a mini size-limited container to pack around 3 or 4 small items?

I hadn't made the sample tank part yet, its still just a logged issue. I was planning on a 5 liter tank, which is enough to online a short range beacon and execute a few jumps with a small ship, but not to pay for the orbital speed matching in most cases.I was thinking a price of 75000 for the container, which would mean the empty tank costs 65000.

Well, the FTT part is currently not active, since FTT hasn't implemented harvesting yet. However, the framework is in place for when that happens. Did my placeholder check for FTT actually disable the distiller? It wasn't meant to do anything yet.

I can kind of answer this! I was playing with Kerbal death in my mod, so I know how to trigger this. Basically, when you kill a kerbal you have to do two things - register them as dead (ProtoCrewMember.Die()) and remove them from the ship (Part.RemoveCrewmember(ProtoCrewMember)). If you register them as dead but don't remove them, you get the KIA screen. However, it still allows EVA/IVA. Simply exiting the ship and reentering it will cause the KIA status to clear.

Updated to 0.2b! Redid the near beacon scanning function to allow for many beacons in range, plus realized I had left the HCU divisor value at a placeholder even after calculating out what it should be. Download from Dropbox 2014-08-27 0.2b -Added handling for multiple active beacons in range. -There is a new GUI button that allows you to step through all active beacons the Hailer can see. -Fixed incorrect HCU costs & fuel exemption -The HCU doesn't charge for fuel used during a jump if the beacon is the IB1, but it was applying that to every beacon. -The toll rate was too low, it's meant to be 2% of cargo weight in Karborundum. -Made the Hailer GUI respond correctly to switching vessels with the GUI open.

To elaborate on what RoverGuy said: Carborundum, or silicon carbide, is the real-life inspiration for the name: https://en.wikipedia.org/wiki/Silicon_carbide#Natural_occurrence And thanks! I'm never sure if my github issue comments are more "color commentary" or "ramblings of a madman." I tend to think of them as a diary of my rocky relationship with C# and the KSP API. The direction indicator is definitely needed, but it was hard enough just getting the damn thing to display and I didn't want to hold up feature release longer than necessary. I'll either see if I can get it to cut out nontraveled portions of the orbit by messing with the preview orbit's epoch parameter or I'll have to implement some sort of visual flair like the Fine Print orbital direction icons.

Released Dev 0.2! CRP Integration and Orbital Insertion Previews. This update will not break ships, but it will throw off a few calculations for ships using the old KBD counts. Older beacons will not have the proper amount of fuel storage. I don't anticipate changing that particular component again anytime soon. Dropbox Changelog 2014-08-26 0.2 -Switched Karborundum to be Community Resource Pack compatible. -All costs and counts of Karborundum are multiplied by 5. -Relative density is up slightly but down per unit. -Karborundum is now non-tweakable by default. -Karborundum becomes tweakable if Karbonite is not installed. -With Karbonite (but not FTT), Karborundum must be produced at the distiller. -With FTT, Karborundum must be harvested. -Added exit orbit preview for non-AMU-assisted transfers. -Added HCU toll per ton of protected material (including crew). -HCU toll is equivalent to 2% of cargo weight in Karborundum. -Revised LB10 velocity transfer, no longer takes exit beacon velocity into account. -I found that this led to more intuitive local transfers. -Interplanetary beacons still use exit beacon velocity to allow players to use it to help shorten their exit vectors. -Fixed an issue where gravity barriers weren't being obeyed.