Majiir

The part mass is ignored. The plugin uses the dry mass plus the fuel times a common density. I'm not sure what it is, but it's in the source code. Jool is green. Kethane is green. I think we can bump that number a bit. Don't worry about balancing; I'll get to all that in due time. If you're building parts, do try to have an accurate measurement of cross-sectional scoop area. I'll be using that in the part config.

How would that work with attach nodes on both ends? I guess the idea is to support decouplers? I heard you were AWOL! Toss me a PM if you have any in-development code I might be able to merge in.

Well... kind of? Part of the problem is that scoops are... well, scoops. They scoop air. There's not much wiggle-room for the cool factor. The center spikes are about as good as it gets. I like this one a lot, actually. The shape is exactly what I had in mind for modifying the PROFAC concept. The cone could stand to be a little bigger (or the compression hardware a little smaller), and it should definitely have a center spike. That, in my mind, is the best candidate. Don't get me wrong, I love the modeling work. I'm just suffering a little cognitive dissonance over here trying to call it a ram air scoop. You know what, though, it might be growing on me. Maybe. Radial scoops make sense (in the Kerbal way) if you've already got a center scoop mounted. Maybe size it so it'll neatly capture anything the center scoop doesn't? The important thing (for physics' sake) is to make sure the bulky compression hardware is entirely in the shadow of the scoop. The scoop interior should also be pretty aerodynamic. The exterior is less important; after all, there shouldn't be any air there since it's all getting scooped up. Of course, nothing stops someone from mounting the radial scoops without a center scoop. I guess that crime against design is on their head.

The problem with deviating too much from the design I posted earlier is we end up spitting in the face of physics. We're not collecting at the speed of a racecar or even the speed of sound; we're at orbital velocity, which is a lot faster. I considered something like your sliding-spike idea. The sizes are a little off, but it could be made to work.

Cheers! Not a problem! I didn't mean to sound annoyed, by the way; I just wanted to be very clear in case someone wasn't paying close attention.

This is a common problem. It's on the list. Also a common request, and now on the list. I'll look into it. The other issue is that the models are in .mu format right now, which as I understand, doesn't lend well to modification. Yeah, it shouldn't be boringâ€â€but it should also really be a scoop. The outer cone could use some slight curvature. And, of course, the Kethane style is a must. (Although, for the scoop, I actually had black/green in mind. Need concept drawings!) Yeah, I thought of that. The compressor in particular will get hot, as will the narrowest areas of the scoop. This is also a gameplay feature; heat dissipation will be important on scoop satellites.

I have bolded the real problem. That is, simply put, the wrong way to check for type constraints in C#. I applaud your timeliness and resourcefulness, but I must emphasize that this is also a wrong way to check for type constraints in C#. I have submitted a pull request on Github with the correct fix and an explanation. By the way, if you find plugin compatibility issues, please notify both plugin authors! (I did suspect this plugin would have a compatibility issue with MajiirKerbalLib, but I didn't suspect someone would have already found it.)

Not entirely true! The rate increases logarithmically. I picked that because it gives a balanced tradeoff where higher warp does get you more data per second, but lower warp gets you data more concentrated in the same area. Thanks. I'll take a look at this. At some point I'll be customizing deposit generation for each celestial body. In the meantime, we get random generation, which I know isn't particularly immersive. Yes! ...but not yet. I'm still getting organized after the handover and I'd like to write up some contribution guidelines. Expect this within a few days. Probably not, since I'm not a big fan of using version control for non-text files, but I might be convinced. That would be great! Take a look at the PROFAC concept: In particular, note the center spike and how the cone is a bit larger so the rest of the craft experiences zero drag. The scoop part should also have the compression/liquification/cooling systems attached behind it. (Those don't need to be as big as in the picture; just make sure it's more than a cone.) Optional features might include a way to close it to reduce drag, as suggested. I'm also thinking of concepts for ejecting non-Kethane gasses. More on that later. [EDIT] I should note, as I have for others in private, that a scoop part likely isn't making it into a release for a little while. There's been a lot of interest in modeling this particular part, which is great. Just don't expect it to be released a week later, since I have quite a bit of coding to do between now and then. If anyone's looking to contribute new part models, consider a 2-meter Kethane tank.

Yep. I'll be expanding on this some time so the deposit distribution makes more sense. Yes, but it won't be for a little while. Maintenance of the current plugin is my priority right now before I add major features. I'm doing the coding. I have some modeling and texturing experience, but I haven't done any for KSP and my expertise is really coding. Dani-Sang supplied me with a model for an unreleased part, so that will tide us over for a little while. We'll see. It'll certainly develop faster than it was with kulesz so busy. I'm still thinking over the long-term timetable. Yes. For best results, I highly recommend grabbing my other plugin, MajiirKerbalLib, which has a more complete fix for the refilling issue. To echo others, thank you for building it to begin with.

Yes. I've added a change log to the first post.

The Kethane Pack is maintained and distributed here and on KSP Modders. If you have bug reports, questions or feature suggestions, please post them to the Github issue tracker for the project and follow the bug reporting guidelines. The Kethane Pack was originally developed by Dani-Sang (concept, models, textures and animations) and Kulesz (plugin). Majiir (that's me) is now managing the project. Keptin created the parts introduced after version 0.1. ------------------------------------------------------------------------- [snip] Last updated October 7, 2014 (KSP 0.25.0) (release notes) Download patch for 1.0 compatability (unzip on top of 0.9.2) License - Kethane Source - Grid Source - Old versions ------------------------------------------------------------------------- Kethane Wiki See the wiki for frequently asked questions, version history, part details and more. ------------------------------------------------------------------------- Have a problem? Read the bug reporting guidelines first! Problem with fuel routing? There's a thread for that. ------------------------------------------------------------------------- Live Development Streams 2013-06-25 - Majiir works on tweaking particle effects until Kethane creator Dani-Sang makes a surprise visit. ------------------------------------------------------------------------- Please note that donations go to Majiir and not any other participant in the Kethane project. I will buy things that make me personally happy, like good coffee beans and k-pop socks. Remember: a programmer is a tool for converting caffeine into code. ------------------------------------------------------------------------- Kethane 0.9.2 Trailer (by Charles Rogers/Umbongo Time) Kethane 0.4.1 Trailer (by Keptin)

Gods they're so ugly, in such a beautiful way. I'll have to try this out.

Just right-click an engine and click "Disable Command". This will disable the function for all engines. Later on there will be a more persistent configuration.

If you mean the satellite command disc thingy, make sure you have MechJeb installed.

I'll look into it, but I suspect it's beyond my ability. This disables the individual engine throttling for optimizing fuel efficiency. Generally, you'll want this on. You might want to disable it if you're building a highly asymmetric craft and you find the system hurts vessel stability. Note that clicking this will disable the command system for all engines.

I experimented with this at length. Unfortunately, simple part-level tweaks are insufficient. (It just results in oscillations that are even worse.) I'll be working on a fix for this eventually, but it will be part of a much more comprehensive control systems overhaul.

I've released a 0.2.1 hotfix. This fixes an issue with the specific impulse calculation for air-breathing engines. I've also added a specific impulse readout for air-breathing engines and legacy liquid engines. (Right-click the engine to see it.) I'm focusing on more automatic features that don't require a UI at the moment. The idea is that anyone and everyone should feel free to install the plugin because it doesn't do anything you wouldn't want and doesn't have a big clunky interface. I'm thinking about interface options for the future, so I'll keep this in mind, but it probably won't be for a few update cycles.

Vanilla mod test release? What is this? It might come in a later release that's more input-oriented. Can you give a scenario where this would be useful?

The download link for version 0.2 has been posted. This version adds a fuel readout and toggle for RCS fuel tanks, much like regular fuel tanks have. It also includes air-breathing engines in the specific impulse prioritization system, which allows for much improved control of spaceplanes.

I'll implement a simple enable/disable flow on the RCS tanks, similar to regular fuel tanks. I can do a more complex fuel feed overhaul at some point down the road.

Nope, thanks for pointing that out. I'll work on a fix. They actually reach NaN (not a number). When I disable the engines, I set the maximum thrust to zero so plugins like MechJeb and Engineer will know the engine can't provide thrust. But, when the engine tries to work out its temperature, it divides by zero. My fix was to ignore the engine's own temperature calculations when it's disabled; that way, it just cools down like any part. I've added it to the issue tracker. I might tackle it in 0.3 or 0.4.

Deployed another hotfix. The current version is 0.1.3, available in the first post of this thread. NERVA engines should no longer turn blue. (But now, I know how to make them turn blue on command... muahaha!)

I've deployed a hotfix for the ship loading issue. First post has updated links. Check out the comments on the issue tracker if you're curious about what was happening. There are a few more bugs on the tracker at the moment, so keep an eye on them and let me know if you have any information that could help.

Why, thank you! I think I'll stop reading right here... Yep, I've encountered this myself: http://imgur.com/nK9hm Don't worry, it's not your GPU overheating or anything. I think the game gets confused when the throttle quickly changes values, and the temperature reading gets into an invalid state. That's my hunch, anyway. If you come up with good reproduction steps, stick them on the issue tracker on Github. That sounds like it's related to an issue I found with flight restarts/resumes. Did it go invisible at around 500 meters range? That would be consistent with what I've already found. (If it happened at 2500m, that would also be consistent. Any other range and I'm not so sure...) I'm most interested in fixing the second issue since it can really ruin the game. If you find that a ship becomes corrupted like that, just quit KSP without saving or going back to VAB/Space Center, and when you start the game up without the plugin everything should be fine. I'll hotfix this as soon as I figure out a solution.

Yes, but that's an issue with the ship control scheme in general, not the feeding order. Revising the entire control system is on my list, but that'll come a bit later.