jofwu

Somebody on Discord told me the same thing DStaal. Turns out I didn't think to try that. Not sure if this is a bug, a mod conflict, or intended/normal behavior... Considering others are aware, I assume it's the latter. If that's not the case and pictures are helpful I can post some.

Can drill separators be swapped out in the VAB? Either I'm blind or it wasn't giving me the option last night. Assuming my eyes work, I'm curious if this was a bug or just not an option built into the mod.

There's certainly more potential for the game to improve from where it's at right now, and wiping the slate of mods we have completely clean would be a hard pill to swallow... But KSP 2.0, built from scratch with the wisdom of the current game in hindsight, could be *really* awesome.

Got a bug and a feature request... Using KIS I placed an MKS nuclear generator (and a few other parts) and then docked it to my ship using a KAS pipe. For some reason the resources in the generator (enriched uranium and depleted fuel) didn't show up in ship manifest. I can do some more digging, but I'm not sure what would be helpful to report? Then an idea that's been bouncing around in my head. Perhaps a big request and/or outside the scope of this mod, but I figure I'll throw it out there... With big ships and bases I often have a hard time figuring out how my resources are being used (or how they could) be used. You can look up in the resource panel and find out that you're using X units of EC per second, but what parts are consuming that EC? What parts are producing it? This mod does a great job showing you where resource storage is at or available. I'd like to see the same thing for production/consumption. I imagine picking a resource from a list and seeing all of the parts which can store, produce, or consume that resource. Pick a part and it highlights to help you locate it. You see two values for each: (1) "capacity", which is the max amount that can be stored (for current configuration) or the max amount that can be consumed or generated (for current configuration, if part is turned on) and then (2) "usage", which is the current amount stored or the current amount being consumed/generated. I think this would be incredibly useful. Say your EC usage seems really high and you need to turn something off. This would make it much easier to locate what parts are using EC and decide what can be turned of. Or perhaps you will be adding more solar panels and want to know what kind of production the existing panels get at your current location. Maybe you're mining ore and producing fuel and you want to know if the ISRU can handle the production increase of another drill. With stock KSP you have to search every part one at a time to figure this kind of info out, so this kind of information would be a huge quality of life boost for me. Just an idea...

Two feature requests that have been banging around in my head for a while now... I often have resources changing at a rate too small for ARP to depict. You get a change of (0.00) units per second, which isn't terribly helpful. Would be nice if non-zero values less than 0.01 displayed in scientific notation. Then a much bigger one... Also perhaps outside the scope of this mod, but I figure I'll throw it out there... With big ships and bases I often have a hard time figuring out how my resources are being used (or how they could) be used. You can look up in the resource panel and find out that you're using X units of EC per second, but what parts are consuming that EC? What parts are producing it? I imagine picking a resource from a list and seeing all of the parts which can store, produce, or consume that resource. Pick a part and it highlights to help you locate it. You see two values for each: (1) "capacity", which is the max amount that can be stored (for current configuration) or the max amount that can be consumed or generated (for current configuration, if part is turned on) and then (2) "usage", which is the current amount stored or the current amount being consumed/generated. I think this would be incredibly useful. Say your EC usage seems really high and you need to turn something off. This would make it much easier to locate what parts are using EC and decide what can be turned of. Or perhaps you will be adding more solar panels and want to know what kind of production the existing panels get at your current location. Maybe you're mining ore and producing fuel and you want to know if the ISRU can handle the production increase of another drill. With stock KSP you have to search every part one at a time to figure this kind of info out, so this kind of information would be a huge quality of life boost for me. Just an idea...

Zeroroller, you posted a new topic rather than replying to whatever mod you were looking at.

I was playing with a base design on the launchpad last night that had deployed Ranger warehouse parts. I had the Ship Manifest window open and noticed that the warehouses were listed as an option for sending a Kerbal to the part. I gave it a shot out of curiosity, and turns out it just destroyed the Kerbal. I'm assuming the fault is on the side of MKS for having the warehouses listed by Ship Manifest. Happy to create an issue report on github, but I wanted to make sure I'm not crazy in assuming Ship Manifest isn't to blame.

KSP Space Race The key feature is the introduction of AI competitors in Career Mode. There are an additional 4-6 space center locations on Kerbin's equator. There's a handful of great spots with sea to the East. When you start a new Career game (maybe also Sandbox and Science variants?) you select your starting KSC location and the number of AI competitors. You have to compete with the AI for Contracts, Funds, Science, and Reputation. There's lots of ways you could take this, but here are a few ideas: The basic World's First and Explore X contracts give most of their reward to the player who completes them first. You only get a little something for following in their shadow. Each Agency has a multiplier for every player based on former dealings. Each successful contract will give you a boost with that Agency, and the sooner you complete it the better. Failed contracts hurt your relationship (on top of the general Reputation penalty). Many contracts are offered to multiple players. You can see if another player has taken one that you have selected. The person to finish it first gets the bulk (or all) of the reward. If an Agency really likes you, they are more likely to offer you exclusive contracts Some contracts call for direct competition. It might ask for players to send up the most tourists in a single launch, and whoever gets the most wins. Or they may ask you to deliver some payload to the surface of the Mun, and whoever gets there first wins. Some contracts call for direct cooperation. For example, it may ask multiple players to contribute to a station together, or visit someone else's base, to get a shared reward. Science could be a point of competition as well. It would probably go too far to say that the first person to collect Science from a situation/biome steals it from anyone else. But you could give a bonus for the first person in each case, encouraging players to go somewhere new. Sabatoge of other players is punished so that the game doesn't devolve into an ICBM war. (perhaps that's open to be disabled by mods for people who want to build in combat) Add a "press center" building where you can check up on what other players are up to, how they stand with different agencies, insight on what tech they have, see what contracts they've taken, etc. Add Strategies that play into all of these new mechanics. You could go a few ways on how the AI works. I don't see a reason to make him actually process launches, burns, etc. that you aren't present for. From your perspective it's mostly just going to seem like they're spawning ships in orbit and sending them around to do contracts. He mostly just needs to be able to keep track of fuel usage so that he doesn't cheat. You'd have to limit how fast he can build/manage. The real trick is teaching him to design ships. It would obviously be best if he could procedurally generate ships for different purposes following some basic design rules. (rather than work with a set of predefined ships) Lastly: Multiplayer? Ideally, this would all be set up in such a way as to allow for playing with other humans rather than AI.

Yes. I can't help with the details because I haven't played with RT since CommNet was introduced. But RemoteTech and CommNet have overlapping purposes. I'm fairly certain that RT essentially turns CommNet off, replacing it with it's own functionality. There's no point to having RemoteTech if you can connect your satellites using CommNet. My understanding is that the next version of RT will build on top of CommNet - changing/adjusting the stock functionality rather than just turning it off and replacing it. @TaxiService, thanks for checking on the ground stations for me. Just a clarification question... When defining a ground station in the config you provide the coordinates and an Omni range. Are you saying that all ground stations automatically work as both an Omni AND a Dish, both using the specified Omni range value? For exapmle, by default Mission Control has a 75 Mm Omni range value. Does it normally act as a 75 Mm Omni AND a 75Mm Dish? (presumably the cone angle is essentially 360 degrees, since it doesn't have to point at anything?) Thanks again!

I haven't played with RT in a while because I wanted to give CommNet a shot. I'm thinking about installing again, but I don't want to give up my current career game. I've also got some USI mods installed, and I'm not sure how well RT plays with that. I would make a backup of my save of course, but I'm just curious what I can expect. Is it possible to install RT, try it out, and possibly uninstall? On an in-progress Career game? I'm aware that I might get a bunch of satellites with no control of course, but I'm more concerned about technical issues from installing/uninstalling on an existing save. Also, totally random side question, is it possible to use KIS to attach and active a RT antenna to fix a probe that has lost control? Edit: One more question. I've found MM configs to create additional ground stations, but they're only configured for Omnis. The help documentation suggests that's the only working option. Is it possible to set the ground stations (including mission control) to dish antennas? I feel like the ground stations should be as good as the best Dish part. I'd rather just build networks around the planets/moons I go to and not bother maintaining one around Kerbin.

That's perfect, thank you! Looks like people are having some issues with it lately, but also seems like there's interest to keep it going. So I'll keep an eye on it.

In stock KSP, your parts are either 100% functional or 100% exploded and gone. There are a few notable and interesting exceptions to this: things like wheels, landing gears, and parachutes. I think the prospect of parts becoming damaged due to misuse is a fun game mechanic. We have to protect those parts, and when things go wrong we have to send out an Engineer to fix them. I'm not talking about "random part failures", as some mods have set out to do. I don't particularly like the idea of uncontrollable failures that require tedious repairs. But I do like the idea of paying for my own mistakes. And I like the idea of adding a small margin of error where a mistake doesn't result in total failure, but rather something which can be fixed. I don't fully understand how part destruction works, but I know that the part files come with various impact tolerances and the like. Hit below the limit and you're okay. Hit above the limit and you're toast. So here's what I would propose: 1. Introduce new "damage tolerance" values to every part. You can use Module Manager to add these, based on some percentage of the tolerances related to destruction. (Say 80%?) 2. Just adding the extra possibility of damage would make things hard. So to balance this let's also use Module Manager to increase destruction-causing impact tolerances by some percentage. (Say 10%) This gives a nice window of room between 100% functional and 100% destroyed. 3. When a part falls into this "damage window" it becomes Damaged. The part (and everything attached to it) is still attached to your ship. You receive a warning at the top of the screen: "Part X has been damaged!" 4. Damaged parts no longer function properly. Some examples of what this implies: Engines are locked in a deactivated state. Tanks containing resources cannot be accessed. Reaction Wheels lose all torque. Decouplers cannot decouple. Antennas cannot deploy. Science Labs cannot perform research. Crossfeed is disabled on any part. You get the idea! 5. To be fully realized, such a mod would change the model and texture to appear damaged, but that's incredibly ambitious. More realistic perhaps is a simple adjustment to the texture to indicate that it has been damaged. And in lieu of anything else it would be nice to just have an overlay that highlights any damaged parts. Of course there would also be a "Damaged!" line on the right-click context menu. 6. Damaged parts can be fixed. There are a few ways to approach this. Perhaps the setting is configurable, or perhaps you'd just need to pick one and run with it. My opinion is that an Engineer is required to fix the Damaged part. Just hop out on EVA, right click the part, and choose "Repair". It may also be desirable to include some kind of "Repair Parts" resource. (whatever the random failure mods are using, I figure) In this case, the ship with the Damaged part would have to have this resource available, and the repair would use up some amount of these. Another possibility is to include KIS integration, and require a particular tool in order to repair Damaged parts. So that's it! Would anybody else find this as awesome as I do? Does something like this exist and I just don't know about it? Thoughts?

Updates to spreadsheet. You can now choose a minimum apoapsis (higher than optimal). The second focus falls on a hyperbola with launch/landing sites as the foci (or for same launch/landing altitudes it falls on a line). I wrote a user-defined function that takes the geometry and tries out different options for focus 2 until it narrows down one that gives the desired apoapsis. Seems to work correctly except for a bug that sometimes pops up when starting and final altitudes are the same. Also something's wrong with the pitch/flight path angle at the landing site. Can't figure out why, because it looks perfect at launch and it's the same equation either way. But I don't see that number as useful anyways. When you want to land you're just going to burn retrograde. Next step I'd like to take it to try out rotation, using the approach described above. But doing that essentially requires performing all of the operations on the spreadsheet repeatedly. That means I either have to pick a set number of iterations or I have to ditch the spreadsheet and program the entire thing. I have the skills to work out the guts of the program, but not to make an executable, build an interface, etc. So I think I'll cast out a net and see if anyone wants to help with that.

@Aethon Not sure I understand what you're trying to say. You need those equations to calculate the time between two points along an elliptical orbit.

Thanks for taking a look at that! I think I had a slightly different equation for e, but regardless I've changed it now to the much simpler c/a. Tried theta for 0, 90, 180, and a few in between and it looks correct now if it wasn't before. I was hoping that would fix my new pitch angle equation, but no. Turns out I should have been using ATAN rather than ATAN2. That change gives good answers. Undefined for 0 theta, limit of 45 as approaching 0 theta, 22.5 for 90 theta, 0 for 180 theta. I need to look more closely at how that plays out in my new sheet though... The old equation is giving different results between 0 and 180. I think the new equation is right on those now that I've made the tangent fix. And I like how the new one approaches 45 at 0 but is undefined at that exact angle.

Ugh! Saw this reported in two places and it made me scream. I mean, it makes for some fun sci-fi, but seriously... What a ridiculous publicity stunt.

I had my proudest KIS moment to date. I sent Jeb/Bob/Bill to build the beginnings of a base on the Mun. I've never been able to do an MKS base before because I bite off more than I can chew. So I decided to take it slow and keep it simple. I sent them with a small science lab, a greenhouse, and enough habitation/supplies to last a while. Unfortunately the Mun has a really long night, and I wanted to keep the greenhouse running if I could. So I also sent a towering ship loaded with batteries, fuel, and fuel cells. Everything arrived in one piece and I was feeling pretty good. Then I realized the power tower had no power distribution. So then I send Val with a power distributor part, thinking it shouldn't be a big deal to stick that on and call it done. She arrives and everyone cheers. Bill goes out to bolt the new part on... And realizes that the stupid thing can't surface attach! Who ever heard of a power distributor that doesn't surface attach!? My skyscraper of a power station didn't have a single place to stick the thing... except for the point on the VERY top. It just so turns out that Val's shuttle is maybe 4 meters or so shorter. Maybe Bill can stand on his tip toes up there and reach across? With expert skill, Valentina slowly scooted over as close as possible, by hovering inches over the ground while making use of the extra RCS. Bill climes to the top. Thankfully the KIS container was close to the top, so he was able to pull it out and stick it on top of Val's shuttle first. Can he reach? Not quite. But there's a solar panel sticking out one meter overhead. He hops up onto the solar panel ever so carefully and crosses to the middle like he's some kind of Munar gymnist. Can he reach? No... no... there! With a few inches to spare, Bill screws on the power distributor and brings EC to his crew far below! I feel like my KIS shenanigans goes south more often than not. I couldn't believe it actually worked that time!

I've updated my spreadsheet with what I worked out yesterday. There's a tab for the super simple case as we had it, for the record, but the main page now handles sites at different altitudes. I'm going to explain it here for the sake of anyone who wants to check it, or for myself if I ever take some time away and need to figure out what I did again. Theta and bearing are easy equations to look up. I've converted the equation I found for bearing so that it gives degrees as 0 to 360 rather than -180 to 180, so that it's friendly with the KSP navball. Next are some vectors inspired by this explanation. Rb is the vector from center of planet to the point at the higher altitude, Ra is the vector to the other point. Rc is the difference between these vectors and Rf is the vector from center of planet to the (optimal) second focus point, which lies along Rc. We use the geometry to work out the point that gives an equal distance (2a) from origin to each site and then to the other focus. Calculate a, c, and apoapsis for the resulting ellipse. Then it's just a matter of using the vis-viva equation to calculate the velocity at each point. Total delta-v requirement is the sum of these. I used the dot products of the vectors above to work out the angles between site locations and the major axis. Phi (formerly alpha) is the pitch angle (more properly, flight path angle). The formula is from here: http://www.bogan.ca/orbits/kepler/orbteqtn.html. For some reason it's giving different results compared to what we had before for the simple case (see simple case sheet for comparison). But I've looked closely and I definitely think this equation is getting the right results. Eccentric, mean anomaly, and time equations are from that last link as well. These are all just needed to calculate the travel time between the sites. I had to introduce a few conditions to keep the equations correct for some weird sign flip cases and such. I tried a few other numbers and didn't see any other problems with the results, but I could still have missed something. I started to look at what happens when we allow an optionally higher apoapsis, but it's not proving simple. I can't find a sleek way to work out the ellipse given the apoapsis (and other info we have). I started looking at a brute force method, using the hyperbolic equation for foci, but it's looking like the equation I'm headed towards (that gives the location of the required focus) is a real monster. I'm afraid it won't have an easy solution. Apparently Google Sheets now allows you to create functions using JavaScript. So my next attempt I think will be to write a function to guess and check until it finds the answer. I'll just pick a focus point, see what apoapsis it gives, and then make the next guess higher or lower until I find a solution within a meter of the desired apoapsis. This should be good practice for the next step, of considering surface rotation. My thought here would be to first calculate an orbit assuming the ground is static. I'd use calculated travel time to work out the final position of the target as it rotates. Then recalculate an orbit using the final target position. Compare travel times, adjust the final target position, and repeat. You're essentially just taking shots, measuring your travel time, and comparing to the target's movement. Eventually you'll be within some reasonable margin of error where your ship and target arrive at the same point at the same time. The REAL trick will be accounting for surface velocity. It plays into your orbital velocity and ultimately changes the game of what's optimal. Consider a hop between two points on the equator. For a non-rotating body, the problem is symmetrical either way. But for a rotating body... If you launch in the direction of rotation, your rotational velocity decreases as you go up higher (you have to travel faster to keep up with the ground) so that the ground is passing beneath you slightly in the wrong direction. This suggests a lower orbit would be more optimal. And you can use that same problem to your advantage if you launch retrograde. You want the ground to pass beneath you and bring the target closer. So a higher hop is better. I'm not even sure what to think yet about north/south components. It's going to be tricky to see how it plays in.

Awesome! I think I'm on the right track for getting the solution for different start/end elevations. The last link I shared confused me because there should be multiple solutions. I realized that it shows the solution where the second focus, F2, is located directly between the two points, A and B. And as I explored how you'd get other solutions everything clicked into place from what the link before was saying. The set of possible solutions for F2 forms a hyperbola where A and B are the foci. So I worked out the math with an example, to wrap my mind around it I drew an ugly looking moon with center of mass F1 and two points on the surface A and B. I conveniently drew them as 3-4-5/6-8-10 triangles so that I could easily locate a second focus, F2o. So the path either way from F1 to F2o is 15 giving a=7.5. Next draw a line through A and B (which conveniently has a slope of -2). This is the x' axis for the hyperbola. The center is located directly between A and B at point M. Then draw a line perpendicular to the last at slope 1/2 through M. This is the y' axis. Since we know the location of F2o we can calculate the hyperbola's semi-major axis as 1/2 the difference of the distances from there to A and B. You get a=2.5. And the distance from A to B is 2c, so you easily get c=5.59. c² = a² + b² gives you b=5. Now we have the equation for the hyperbola on the x'-y' axis: x'² / 2.5² - y'² / 5² = 1 If you want to vertex (on the B side of y') just use y'=0 and you get x'=2.5. I rotated and shifted back to x-y so I could plot the point, called F2v, accurately. I also eyeballed the mirror image of F2o accross the x' axis. And there's a hyperbola taking shape! This hyperbola represents all possible solutions for the second focus of an ellipse with known focus at F1 and two points (A & B) on the ellipse. After thinking about it, I'm pretty sure F2v is the optimal solution. The distance from F1 to A and B is fixed for each. As you slide F2 either direction from the vertex the point is going to get further from both. And that means the semi-major axis of our ellipse is getting bigger. So just as with the Ra=Rb=R solution, the optimal orbit happens when the second focus is located between the two points! Pretty cool! Here's what some of those orbits look like for my example: Need to process the implications of this, but wanted to share... Edit for some idle thoughts... It's neat to see how the orbits for F2o and F21 in that last image have the same energy cost. It's probably due to the concept that getting into orbit is best done with a Hohmann transfer from the surface. So there's this natural tendency for me to think that shallow is better than high. But those paths have the same energy and the steeper one sure would be easier to land. Also realizing that if you want to have the option of trying a less than optimal SMA for these conditions, you have to deal with the issue that there's two solutions for each SMA. (one with a focus on either side of the hyperbola) Lastly, I wonder if the other side of the parabola (the half on the other side of y') has any meaning...

The problem with this is that for different elevations at each site (r1 != r2) I don't think you can assume θ/2 is the correct angle. The points would not be mirrored across the SMA, so θ isn't perfectly bisected. Edit: Found this: http://sketchexchange.keypress.com/forum/showthread.php?117-How-can-I-construct-an-ellipse-given-one-focus-and-two-points-on-the-ellipse&s=1257b4aa7ad910355cc8a4319036ffd7 Hard to say, but it might be useful... @Aethon, didn't have a chance to see your links right away. This is great, thanks! The second isn't relevant, but the first explains very well how to come to the optimal solution for the basic case.

@wumpus Yeah, I'm not trying to figure out the minimum delta-v to visit each biome. This is just looking at a single trip. The travelling salesman problem of visiting biomes would be an interesting one, but not important here because I'll be returning to base and refueling each time. Honestly, looking at early results, efficiency isn't even that significant. You can add unnecessary additional height for minimal extra DV cost. But I think this is useful anyways as a "manual maneuver node" of sorts. Rather than guessing at where to point and how long to burn, you just enter two sets of coordinates, point, and shoot. Then look at the map and make necessary adjustments. Just saves from having to do lots of in-the-moment guesswork for the hop. I was thinking the same way for when the time comes to try introducing rotation. I'd calculate the orbit first assuming no rotation to get an estimate for T. Use that T to calculate the final position of the landing site. Re-calculate to this new site and get a new T. Repeat until the difference between two T's is within some margin of error. I think that would work, and seems very doable. The hard part will be considering initial/final surface velocities and working out how this plays into determining the optimal orbit. If nothing else it makes delta-v for the two burns (launch and landing) asymmetrical. But anyways, for now I think I want to feel good about the simple case, allow for different apoapsis, and then look at different starting/ending elevations. @Armisael I had a thought this morning... We have coordinates for the focus of the ellipse (planet center, set to the origin) and the two sites make up two points on the ellipse. There are an infinite number of ellipses to fit these points, but can we use that to calculate eccentricity as a function of semi-major axis? You could then take the derivative with respect to eccentricity to get the minimum sma (and corresponding e). This would help a lot for the non-optimal case and for sites at different elevation. I found an answer to the question here (http://math.stackexchange.com/questions/547045/ellipses-given-focus-and-two-points), but I don't quite understand how to derive or apply the solution given.

, but Right, but for a big ship it can be hard to find all relevant parts buried in there.

Thanks! One more question, capacitors aside... What if I have 3 days of EC with means of producing a surplus? How does that work? Does it understand how to include what you can potentially produce?

I've got a question about how the catch-up processing works with life support... I'm curious how it will play along with the capacitors from near future electrical. Capacitors hold "Stored Charge", where 1 unit of stored charge = 1 EC. The trick is that to be used they have to be "discharged" which rapidly drains stored charge and fills any batteries with the corresponding amount of EC. They recharge just like batteries except there's a cap on how fast they can be filled. The discharging (as I understand it) is something that happens manually. So let's say I have a base with 1 days supply of EC and 5 more days supply of stored charge. If I were manually monitoring the base, I could discharge capacitors as needed and the base could run for 6 days. But what happens if the ship is out of focus? If I go to another ship and come back 3 days later, will my Nom-O-Matic have carried on at the initial rate or am I going to be behind on Supply production because of a lack of readily available EC?

Is there a way to see how much torque you potentially can get out of reaction wheels?