Jump to content

Zhetaan

Members
  • Posts

    1,053
  • Joined

  • Last visited

Everything posted by Zhetaan

  1. Not to be unnecessarily picky, but you're describing a geostationary orbit. Geosynchronous orbit always remains at the same longitude; geostationary orbit always remains at the same point. Snark has the best approach for a direct rendezvous with your target point; there are few problems in KSP that mathematics won't solve. If you miss your mark, however, then the second-best option is to get the altitude right and go for a circular polar orbit. In this fashion, you're just about guaranteed to get your objective within three hours (a six hour day plus the orbit going round the back of Kerbin means you make two tracks over the ground). The only way this won't happen is if your target window is very small and Kerbin rotates too far each time you pass near. In that case, your problem is orbital resonance: a half-hour orbit on Kerbin's six-hour day is a simple integer ratio that means you exactly repeat your ground track every twelve orbits (ground track in this sense means a unique orbital path as a projection onto Kerbin's surface; it has nothing whatever to do with rovers or other ground vehicles). If none of those twelve is close enough, you'll never get where you need to go. The solution then is to destroy the resonance, which you can do by modifying inclination or eccentricity. Each of these has a drawback: changing inclination changes your ground track at the cost of missing certain latitudes; changing eccentricity changes your ground track at the cost of missing certain altitudes.
  2. ESLD Jump Beacons may be what you seek. The beacons are an in-game set of jump gates; there are three different kinds of stationary beacon with different range and tonnage limitations, and one mobile beacon that can jump itself (and the ship attached to it). It's meant to be in balance with the game mechanics, so it isn't cheap to set up and use the beacons. The beacons have altitude and gravity requirements (they have to be well out of the gravity well), and they have to be at both ends of the jump (so the destination beacon has to get there the slow way). They also take a special fuel that can only be found in a few places (however, you can set the config for other options) and they conserve momentum until you unlock some esoteric high-tech gear. This means that, for example, if you decide to jump from Kerbin to Jool, you'll go there ... and take all of your Kerbin-relative velocity with you. Thus, you'll need to pack all of the dV of a Jool transfer and use it all at once when you arrive, which usually means that it is less efficient. If you decide to use the high-tech gear, you will have near-zero relative velocity to Jool, but that will cost a lot more of the special fuel. It's an interesting mod, and I like it a lot, but it does come with a new set of rules that makes you rethink orbital mechanics on a system-wide scale. Hohmann transfers minimise relative velocity differences; with ESLD, you have to consider relative planetary motion coupled with the beacons' orbital motion in order to reduce the cost of the jump. It's very satisfying for me, but it can be frustrating if you're not expecting the magnitude of velocity differences between inner-system and outer-system orbits.
  3. MECO (Main Engine Cut-Off) Also, for the support forum, PEBKAC (Problem Exists Between Keyboard And Chair)
  4. @nightingale: I noticed that it is possible to repeat the Mun and Minmus Probes strategies; all the others have a variation of the 'Must not have landed on <body>' requirement. Since v1.2.3 changed the Mun/Minmus probe strategy rejection criteria so they were no longer mutually exclusive, I wonder whether this is a bug or intended behaviour. If it is a bug, you have my apologies for adding to the 1.1.3 workload.
  5. 4000 Funds/unit is still five times more expensive than the next-costliest resource, EnrichedUranium. Also remember that the original K+ had little sample tanks of Karborundum that people could (and did) spam on their vessels; they were simply very expensive. Nevertheless, there's nothing preventing us from adding a ModuleManager config that says: @RESOURCE_DEFINITION[Karborundum]:AFTER[KarbonitePlus] { @isTweakable = false } ... and saying that the difficulty is part of the mod. As it is, a jump that costs 250 Karborundum costs a million Funds, which admittedly is not difficult to find, so there is something to adding an extra zero to the cost. Ten million Funds for a single jump is a lot less attractive. I thought about the idea of placing the HCU techbox at the bitter end of the tech tree, but that interferes with resupply regardless of the initial source of Karborundum.
  6. I'm not certain I understand your idea here. If my interpretation is correct, then it won't work very well. Your mothership and lander will both fall towards your target body. Being at the same height for the entire fall, they each will gain the same amount of speed and will arrive at the same time. The mothership will then begin its escape; the lander needs to slow down to approach, land, take off again, rendezvous, and match velocities with the mothership. By this time, the mothership is gone. If you undock a few hours out from Pe, you can gain some time by burning to increase speed, but that is countered by needing to burn again to shed that speed once you reach your target. Total time saved will be measured in minutes, at best. That being said, it is possible to do something like what you want. The idea is essentially an exaggeration of orbital error: if you launch two ships from Kerbin to Jool within five minutes of one another, their arrival times can be days apart. A miniscule amount of that has to do with optimising the transfer window, but the bulk of it has to do with error in the burn. Miscalculate your direction by an arcsecond, or hit the MECO button a tenth of a second off, and you might not even get the encounter; hence mid-course corrections on most interplanetary transfers. It can be very sensitive; for an example, launch one ship to Jool and after the burn and decouple something from it at near-zero force. The .01 metres per second of drift isn't much but it adds up to a lot of metres over the roughly twenty-five million seconds it takes to get to Jool. Provided you undock your lander and give it the push it needs to be sure it arrives first, you can certainly pull this off if you give yourself enough time for the error to build up. The point of entering a moon's SoI is not enough time. On the other hand, I'm not certain whether you're doing this for the official Jool-5 challenge; if so, be sure that sending what amounts to a flotilla is not against the rules.
  7. 3 is the best, mass-wise. 1 requires you to pack transfer stages for five landers, which means you have to pack additional dV into the mothership to move the transfer stages. 2 is better, but if you're moving the mothership around anyway, why not just go all the way and use the mothership to move within the system? Another possibility is to use an interplanetary tug to get everything to Jool, but then your 'mothership' is, in turn, an intraplanetary tug. That way, you can, in essence, spiral in to the system (or out) carrying only the mass of what you need to visit the moons (are you discarding landers as you go?) and avoiding the essentially parasitic mass of your return vehicle. Then you can return to the return vehicle and return to Kerbin. Be sure to incorporate elements of 4, too--you want to encourage the moons to mess with your orbit, if the end result puts you where you want to be. Free dV is the best dV. Another option is a bit like 4: you come in with a low Pe to Jool, and as you capture, you toss away landers when your Ap is at the right orbit. You can set this up as a multi-burn manoeuvre, going round Jool before burning for a lower Ap (and also to let the alignment favour a lander's transfer window), and it saves you the dV of having to raise and lower your landers' orbits to go wherever they need to go. Then you only need them to pack the fuel to come back.
  8. What 'relative inclination' has to do with inclination: If inclination is the angle of your orbital plane compared to the equatorial plane (or ecliptic, or whatever), relative inclination is your inclination relative to the orbital plane of whatever you want to rendezvous with. Its only relationship to your orbital inclination is that both compare the tilt of your orbital plane to something else. Orbital inclination compares it to the parent body; relative inclination compares it to another satellite. The Mun is a bad example for this because it orbits at zero inclination already; a standard eastward launch puts you in a matched orbital plane automatically. Minmus is a better example; twice per day, the KSC passes through Minmus's orbital plane. This is true of every point on Kerbin's surface up to six degrees of latitude away from the equator, six degrees being Minmus's orbital inclination. At points further north and south, it costs far too much fuel to try to match inclinations while launching; you are better off launching and then correcting your inclination later. How to match your orbits: What you need to calculate is the longitude of the ascending node. Here is another discussion about a related topic (writing a kOS script to launch satellites into specific orbits for contracts), but the basic idea is this: let us consider an object orbiting Kerbin in an inclined orbit. The points of intersection between the inclined orbital plane and the equatorial plane--where the orbiting object 'bursts through' the equatorial plane, so to speak, are called the ascending and descending nodes. The ascending node is the one where the object breaks the plane in a positive normal (north) direction. But where is it in 3-D space? If I launch a rocket into LKO with a ten-degree inclination, and launch another one an hour later, the two resulting orbits are not coplanar. The two rockets' ascending nodes are at different points along Kerbin's celestial 'equator'. The longitude of the ascending node tells the angle of the ascending node with respect to a line drawn from Kerbin's centre to a fixed point in space. In reality, we use a far-away star for Earth-orbiting satellites, but KSP has no far-away stars, so it's a direction in space that points to nothing. The important part is that it is Kerbin-centric, but no co-rotating: in other words, it only pays attention to Kerbin's location, not its orientation. All objects orbiting Kerbin at a nonzero inclination have a longitude of the ascending node with respect to Kerbin's reference direction, and the value of that longitudinal angle is a fixed property of their orbits. To match for a launch, you need to find out what the longitude of the ascending node is, figure out your own celestial longitude (surface longitude will not do, because it rotates) and, when the two are equal, launch into an orbit matching the inclination of your target. Once you know what the reference direction is, you can calculate KSC's current orientation using the time of day. I do not know whether the reference direction precesses with Kerbin's orbit around the Sun or is utterly absolute; if it is absolute, you will also need to factor the time of year. You may also be able to calculate it based on the UP direction, but this is only if you have a core or command pod that faces up (I leave what to do with exotic spaceplanes and other craft as an exercise for the reader).
  9. I think the higher Ore concentration increases electrical consumption because the ISRU has more to work with. I understand the mechanic as this: A drill consumes a set amount of EC/second. The EC consumed does not affect the Ore produced; it is only altered by the concentration (or an Engineer, but let's assume a robotic miner). This is because the drill digs up x tonnes of 'rock', not x tonnes of Ore, so having the drill on a 1% deposit or a 100% deposit is going to show the same electrical draw. The ISRU consumes Ore (and makes fuel) much faster than a typical drill can supply it. Thus the ISRU constantly stalls; it never gets up to full speed, so it never gets up to full electrical consumption. Once you supply it with more Ore (because you are in a better spot and are digging up more Ore), it works harder and takes up more power. There is a limit at which you supply Ore faster than the ISRU can process it (easily seen as filling Ore Tanks), but it's pretty high up compared to typical drill output. Once you hit that limit, though, your EC usage plateaus. In terms of the practical use of a robotic miner, @cantab is correct; in most cases, the best thing to do with a mining/processing outpost is to let it work for a year before the Kerbals arrive to take the fuel, a la the MAV in The Martian.
  10. I dub thee Mount Lookitthat. I shall found a colony there and call it Plateau.
  11. Well, if you want to come back through the beacon. I thought that went without saying; my apologies for being unclear. In any case, that only supports the idea that the destination beacon doesn't need to have Karborundum in it.
  12. @bewing, that's absolutely true, and there are other good examples of this, as well: you can't put pitchblende in a reactor and expect results, but the uranium in pitchblende is obviously energetic. Geschosskopf's contention about burning crude fuels is valid only for those fuels that release their stored energy via combustion (e.g. petroleum). However, there is still a valid thermodynamic concern here. To borrow your analogy, the idea that you can extract deuterium, fuse it, and get more energy than you put into extracting the deuterium is correct and fully supported thermodynamically. What is not supported is the idea of taking the fusion products, fissioning them back into deuterium at low energy cost, and fusing them again to get even more energy. It is this second idea of taking reaction products, splitting them back into reactants, and combining them again for a net energy gain that is the problem. First, the evidence: the fact that the fuel cells in the game use LF+O is evidence that the process is chemical. The fact that the parts are called 'fuel cells' is more evidence. The descriptions of the ISRU parts go further and heavily imply that the process is, if not electrolysis of water, then a direct analogue. That's where the issue lies: if Ore simply happened to contain something usable as fuel and something else usable as oxidiser, and the only preparatory steps needed were extraction and purification, then it would be as you describe in your deuterium analogy and I'd have no concerns about the process being energy positive (getting 100% LF or 100% Ox from the same Ore is another discussion). But if Ore is convertible into LF+O via electrolysis, then the theoretical minimum energy you need to accomplish that is, by dint of thermodynamics, exactly equal to the theoretical maximum energy you can extract from recombining those converted products in the same (reversed) process. That being said, a lot of it is moot for this game. The fact Ore that can be converted 100% into LF or 100% into Ox simply breaks chemistry. The devs acknowledged it and gave good gameplay reasons for why they chose to do this: I simply don't agree with those reasons. Fortunately for me (thanks again to the devs), five minutes and a configuration file later, there's a mod for that.
  13. Have they updated Asteroid Day yet? The Sentinel camera (which, if I recall, was the only part from Asteroid Day not made stock) would 'find' asteroids that threatened the planet next out from its orbit, so putting one between Dres and Jool would generate new asteroids near Jool. If you find them already there, then it takes a lot less brute force to move them where you want them. For a pure-stock solution, you could start at Dres instead of Kerbin. Good luck with the launch windows.
  14. I concur, for two reasons: 1. I fully agree with @rasta013. Sending beacons as probes to far-flung places and fuelling them after you get a Karborundum infrastructure in place is a valid, often desirable gameplay strategy, especially in career. It's a little reckless (I sent solar panels to Eeloo once: oops), but that's very Kerbal. 2. Going along with allowing recklessness, you're going to need to send Karborundum anyway if you want to come back. But the possibility of being stranded by an unintentional one-way trip to somewhere really far away creates an opportunity for a fantastic rescue mission from a gameplay point of view, especially if you run life support mods: my mission to Jool, for example, only needed a few months', rather than a few years', worth of life support supplies. Throw a spanner in the transport and, for my time, that's a much more interesting game. In fairness, the HCU allows the transport of Kerbals as well as Karborundum, so perhaps the only limitation on such a mission is how fast more Karborundum can be acquired. There is an opportunity to extend the mod by splitting those functions: one kind of HCU for Kerbals (available earlier in the tech tree) and another for Karborundum (available last).
  15. Well, it took a month (real life strikes again!), but I've made some progress. Warning: long post ahead. Summary (this is the on-topic part; I haven't forgotten you, @davidpsummers!): There are two ISRU converters and two kinds of fuel cell. I chose not to consider the drills in this first pass because drilling Ore is simply moving it around--it's supplemental, not integral, to the conversion process. The conversion of electricity into fuel and then fuel into electricity is the loop that breaks thermodynamics: because Ore doesn't also come out of the fuel cells for potential recycling, I cannot reliably gauge its involvement in the process. The two kinds of fuel cell are interchangeable (with a scalar multiple) in terms of production of electricity and consumption of fuel: the Fuel Cell Array produces and consumes exactly as much as twelve Fuel Cells (in spite of its visual model and the description in the editor). The mass, EC capacity, impact and thermal tolerances, &c. are different, but again, they have nothing to do with power conversion, so I ignore them. The ISRU converters are completely different from one another: each requires the same amount of electrical charge (30 EC/s) for any of its conversion processes, but the smaller 125 takes fives times as much Ore to produce half the fuel in a given period of time compared to the larger 250. In terms of mass efficiency per unit of Ore, the 125 is 10% mass efficient when producing LF, O, or LF+O, and 8% mass efficient when producing Monopropellant. The 250 is 100% efficient when producing LF, O, and LF+O, and 80% mass efficient when producing Monopropellant. This is, as I said above, not really relevant to the fuel-power-fuel feedback loop, but I do find it chemically interesting that the 250 is able to take the same piece of Ore and convert it into 100% LF or 100% Ox. I'll be revisiting that balance later in my own playthrough. In terms of electrical efficiency, the 125 costs 12 EC/kg for LF+O and 15 EC/kg for MP; the 250 costs 6 EC/kg for LF+O and 7.5 EC/kg for MP. There are no MP-based fuel cells, but since it's less efficient anyway, the really important figure is the 250's LF+O conversion rate. That's the cheapest one, meaning that you get the most fuel for the least power. Compare the Fuel Cell (Array): its electrical efficiency is 80 EC/kg: more than thirteen times the electrical power produced as the 250 consumes. 5 Fuel Cell Arrays (90 ec produced) will exactly operate 3 Convert-O-Tron 250s (90 ec drained). These will draw .10125 LF/s and .12375 Ox/s at a total mass loss of 1.25 kg/s. The Convert-O-Trons will produce 1.35 LF/s and 1.65 Ox/s at a total mass addition of 3 kg/s. This means that, so long as Ore is supplied and neglecting the radiator mechanic, such an assemblage will produce 1.75 kg/s of LF+O without any external energy input. In other words, the quintessential effect is to pass Ore through it and get this much LF+O for absolutely nothing. Providing the requisite Ore is a separate issue, a question of supply versus demand, and therefore more economic than thermodynamic. The point is that if the Ore is available, then howsoever it may be supplied, this device causes it effectively spontaneously to turn into that much LF+O. Because the conversion produces more energy (chemical) than is put into it, this device is a perpetual motion machine of the first kind. Thermodynamically speaking, one may as well throw a tarpaulin over the assemblage, write PHILOSOPHER'S STONE on it in big, block letters, and go prospecting for lead. Including radiators increases the electrical consumption by less than 1%, but even if the demand were 100% (i.e., so high as to require double the fuel cells), there would still be a net production of fuel. Let's look at it in terms of electrical energy: One Convert-O-Tron 250 will supply enough LF+O to power 22.222222... Fuel Cell Arrays. In integers, 9 Convert-O-Trons will power 200 Arrays. The Convert-O-Trons will produce fuel at a cost of 270 EC/s. The Arrays will produce 3600 EC/s from that fuel. Thus, this device will produce a net of 3330 EC/s. Turning it back into a more intuitive comparison, one Convert-O-Tron can ultimately drive the production of 400 EC/s--of which it consumes 30, for a net of 370 EC/s. Put simply, the only restriction to powering anything with this arrangement is the availability of Ore. Otherwise, you can just keep adding converters and fuel cells to satisfy any power need. Therefore, the fuel refinery on Pol needs either a better location or better drill efficiency; those are the only two reasons that you should be running out of power there. Now, for the thermodynamically inclined: In my own game, I've experimented with both increasing the power requirement for ISRU and reducing the power production of the fuel cell. My current settings (I haven't had the time to thoroughly test them) are to increase the conversion cost to 40 EC/s for all processes and to increase the fuel consumption of the fuel cells by a factor of 10. This makes fuel and power production break even, but the need for radiators to have good efficiency forces the ISRU to cost more to run than the fuel cells can supply, in any configuration. The best efficiency, insofar as I've calculated it, is 99.38%. That's still unrealistically good, requiring a single solar panel or a single RTG to put it over the top, but it's not 100%, and in a world of magical momentum-dumping reaction wheels and infinite EVA fuel (just remember to come in out of the cold every few hours), I think that fits the overall style. Realism is for the RO crowd. Additionally, I really didn't like the '100% LF or 100% Ox' conversion potential of Ore, so I reduced the efficiency of the 250 by a factor of five, which means I pretty much need to send an engineer now. It also reduces the value of asteroids a lot, but on the other hand, I was visiting asteroids back when they weren't worth anything at all, so it's not really a net loss from my point of view--especially when the blasted things keep spawning on me.
  16. @rasta013: I have that one, too. I wouldn't say it costs a tenth, though--I've started a new career with CTT, so twenty thousand or so science points later, I think it about breaks even. In fairness, RoverDude went to a lot of trouble to honour the balance of the sheer power that Karborundum represents when he built K+, so it makes sense that the overall costs of either of these 'Go directly to Jool, do not collect 200 Funds' drive would be comparable. The Alcubierre drive has its own, different limitations, as well. You can't transfer the exotic matter to another ship, for example. You need either some serious power generation capacity (which takes up precious volume inside the warp bubble) or else some equally-serious power infrastructure (giant solar charging stations, anyone?). Additionally, it's something of a different mechanic to use--both are fairly fast in-system, but even the Alcubierre drive takes a while to cross the space between stars.
  17. AMT is actually a different mod: it is all about finding random (sometimes rare) resources in asteroids. ART is about turning hollowed-out asteroids into giant storage tanks. Also, it gives a cool 'Mass Driver' engine that runs on Electric Charge and a Rock resource--I got it originally because I wanted to fly a rocket that ran on real rocks in it. I think a lot of AMT was stockified along with Regolith--which may be why asteroids produce Ore, too--so if they don't also produce XenonGas, it probably isn't hard to trick them into doing so. But that's beside the point. I'm unconvinced that there is any stock option that can, in any configuration, provide the kind of challenge necessary to balance the mod. The trouble with Xenon is that a reactor with sufficient Xenon storage plus time warp equals essentially free travel. But time isn't a good balancer: forcing you to wait is boring. Also, to quote the original original post, 'Time is the ONLY thing you save with the beacons,' so any mechanic that makes you play a game of hurry-up-and-wait defeats the purpose. Honestly, I never fully appreciated how totally overpowered click-and-you're-there beacons are until I looked into how much effort went into making this mod work. @Booots can give a better answer here, I'm sure, but if I'm not mistaken, the actual 'move-ship-from-here-to-there' code is probably a fairly small part of the overall mod. The bulk of it is the calculation of costs, line-of-sight, minimum altitude, drift, velocity mismatch, and everything else that goes into limiting how well the beacons work--or whether they work at all--in a given situation. This all implies that to abandon Karborundum is likely to unbalance the mod. Well, okay, we can do that, right? Unbalance is not a dirty word; if you're doing the coding, you can do whatever you want. But to what end? All of that goes to say that if the mod allows other options for a fuel resource, then there are several ways it could go: Keep Karborundum: Either as a K+ dependency, As a CRP resource (with K+, if present, as an expansion), Or as a CRP resource without K+ integration (using stock parts and ignoring K+), but without any other link to the USI constellation. Unhook it from USI completely, but keep the current balance by using a new, different resource that is functionally equivalent to Karborundum (such as Exotic Matter, Antimatter, Scrith, Tachyons, Gleipnir, General Products Hull Material) in terms of cost and difficulty. Scrap balance somewhat and use a stock resource that has either been modified to be more difficult to obtain or else has been expanded into situations beyond its original scope. XenonGas was discussed, but you could require SolidFuel and achieve similar difficulty (though importantly, not cost) because the only way in stock to haul SolidFuel around is to haul it in a solid rocket booster. Really scrap balance and use standard stock resources, or a new resource that is not functionally equivalent to Karborundum in terms of cost and difficulty. Use no resources. 5 already exists; it's called HyperEdit. 4 makes these the 'cheaty, easy jump beacons' that we're trying to avoid--even if only partly. 3 is interesting as a gameplay option; it's a sort of easy mode that works like unto the 'buy Karborundum in the VAB' configuration file but with stock resources. Maybe it is best compared as the AntennaRange to the standard version's RemoteTech: it's easier, but a little different and directed to a different target demographic. I have no problem with this as an idea; there are likely plenty of people who would love to try this mod without the hassle of yet more resources. However, given that the standard package does include the easy-mode configuration file, this may be redundant for all purposes except the 'no extra resources' crowd. 2 makes a lot of sense as a configuration for those who want the full ESLD experience in a completely stand-alone mod. Honestly, if not for the fact that Karbonite provided an open mining and refining mechanic that he didn't have to write, I think TMarkos would have seriously considered this. With stock ISRU, you have options he didn't have, and you can bring it to life. 1-3 is my way of saying that you keep the current CRP stats for Karborundum, but you do your own thing with it and ignore what RoverDude does with K+. Those of us with the USI constellation will run into no difficulty unless the two of you have uses that conflict--i.e. you build an engine that uses Karborundum or RoverDude makes some kind of jump drive that costs a tenth what the beacons do. 1-2 is more or less already present; in the presence of FTT, the acquisition mechanic changes slightly. FTT provides the fancy K+ torch drives, so getting back from the Sun or Eve after a Karborundum run is suddenly a lot easier. In this case, the mod won't let you distil Karborundum from Karbonite; you must harvest it. 1-1 is also more or less already present, but it's also the obvious status quo. I prefer a combination of options: I'd like to see the mod expanded with options for both the easy-mode mechanic of 3 and the stand-alone mechanic of 2, but I won't use those, personally: I very much like the K+ detection and dynamic self-modification that this mod currently has.
  18. XenonGas cannot be produced in stock. You can send tankers to your heart's content, but there is no harvestable form anywhere. Since you downloaded the entire suite of RoverDude mods, you should note that you can find a little Xenon in asteroids (courtesy of Asteroid Mining Technologies, I think) and I believe that both the USI nuclear reactors and the Near Future reactors produce Xenon as a byproduct (as nuclear reactors do in real life). The costs are a little different: in the current iteration, XenonGas is valued at 4 Funds/unit, whereas Karborundum is valued at 400 Funds/unit. There used to be a 'Karborundum Sample Tank' in the K+ tableau which gave 25 non-transferable Karborundum, but it cost 100,000 Funds in the VAB. That was just the tank. The Karborundum price was added to that. Also, please don't misunderstand me: I am not averse to more choice. I am averse to more choice that leads to cost incompatibilities, especially if, as the rumours say, XenonGas is getting a balance pass in KSP 1.2. The real risk with stock integration, or any integration, is that you lose control over the resource costs and so forth. It's like the bimetallic standard for money: when the market unbalances the price of silver versus gold, everyone trades the expensive one for lots of the cheap one and you end up with a de facto monometallic standard. Add in the fact that Kethane's finiteness (you are correct on that) may well make a good cost comparison impossible because of the number of variables--well, I'm interested in simplicity.
  19. Hello and congratulations on the release! I've been following this with some interest for some time, and though I am by no means an old-timer, there are a couple of things I can throw at you from the annals of history and elsewhere to continue to discuss some of the questions that have come up here. First, the hard-coded dependency on Karborundum, as I understood it, was created because this mod invented Karborundum. When he released Karbonite, RoverDude left an open invitation for people to expand it, and TMarkos took him up on that invitation with this. Karborundum's reason for existence was to be a fantastically expensive, more fantastically difficult-to-harvest unobtainium to balance what otherwise amounted to an in-universe Hyperedit, and ESLD was built around it with that mentality. It tied the acquisition of Karborundum into RoverDude's Karbonite/ORSx, then Karbonite/Regolith resource framework (which is now essentially the stock resource framework) as a way of outsourcing the drilling/mining part, leaving TMarkos to focus on the beacons and their operation instead. RoverDude, in turn, liked the idea of a super-powerful, super-difficult-to-obtain, essentially-endgame resource, so he incorporated Karborundum into his mod constellation as K+ and expanded it with other stuff. Using it as some kind of equivalent to (warning--nerd moment) Stargate's naquadah and naquadria for engine fuel, for example, was RoverDude's idea. That's why this mod ships its own Karborundum tanks instead of using the ones that are now available in K+; you originally needed Karbonite (so TMarkos could use Karbonite's drills and ISRU converter) but there was no way to store Karborundum because there was no other mod that supplied it. My point is that the hard-coded dependency is not so much an error to be fixed as it is a feature of the mod, in much the same way that beacons are a feature to use instead of Hyperedit. Given what it's supposed to do, calling it shameful to be hard-coded is equivalent to saying that it sucks that Kethane is hard-coded into the Kethane mod, or that Oxygen is hard-coded into TAC Life Support. That being said, so long as you can maintain some balance in terms of Karborundum's availability and value versus what the beacons do, there's nothing keeping you from setting up ESLD to use something else and having it work just as well. As far as availability, there are still configuration files for putting Karborundum in other places (I recall that Tylo, Dres, and Ike were the locations used) as well as a file for letting you purchase it in the VAB, if you want to use what already exists. The next-most-expensive resource, I think, is Xenon, and Xenon is currently available in stock only in the VAB. There may be opportunities there. The only remaining issue, then, would be those players who simply do not wish to contend with another resource when they already have resource-adding mods such as Kethane. The way it used to work was that if you had RoverDude's full suite of mods, those (warning--nerd moment) Stargate-esque engines would be completely overpowered if Karborundum was easy to get, so you had to harvest Karborundum from Eve, Eeloo, or just above the surface of the Sun. However, if you only had Karbonite, then the only thing that used Karborundum was ESLD and so you could turn Karbonite into Karborundum with ISRU at some awful efficiency. (@Deimos Rast) I think the conversion was less than one Karborundum for every thousand Karbonite--I never bothered with it and went sundiving instead. Obviously, the easy thing would be to simply declare the dependency, but all of the functionality that Karbonite provided exists in stock parts now (essentially unchanged, even), so changing things to use the stock drills and ISRU instead of the Karbonite drills and distiller is certainly a valid course. The short version is this: Karborundum is a dependency for reasons of balance, and eliminating that dependency requires the mod to use something similarly expensive to maintain that balance. No such resource exists, so doing this may create more problems than it solves. Second, on the subject of interstellar beacons, without knowing the scale of distance between stars for the various packs that use multiple stars, you might have the best luck by saying that the energy cost of beacon transfer over arbitrarily large distances approaches some asymptotic value rather than trying to calculate distances that, themselves, are likely completely arbitrary, or worse, having to write some detection code to identify stars, catalogue stars, determine whether two stars are a binary system, rewrite it all and scream in frustration when someone puts up a rogue planet pack for Kopernicus, &c. If need be, you could even technobabble your way out of it by saying that the beacon works by taking advantage of an inverted relationship in physics: in orthospace, the speed of light is finite-but-large, and it takes infinite energy to accelerate a mass to that speed. In whatever hyperspace the beacons use, the speed is infinite and it takes finite-but-still-large energy to accelerate things to that speed (more likely, it enters at that speed as some sort of superneutrino, because in a universe with an infinite speed of light, space, time, and matter cannot exist). Once this is done, well, speed is infinite, so the cost to go to the next star is the same as the cost to go to the next galaxy--or to the other side of the observable universe (because when there's no time and space, getting anywhere is a snap). The caveat and balancing cost in these ultra-long-distance cases would be more that the receiving equipment (and the fuel for it) has to be sent there the slow way first. In short: just set some high, fixed, base price for interstellar transfer (defined as anything beyond a minimum distance) and leave it at that. Correcting for the disparate stellar velocities will keep the costs random enough to avoid being too predictable. Additionally, there is a market for some sort of long-range in-system beacon. Anyone who plays with OPM or RSS-scaled systems will have much larger distances to cover, though it should not be too difficult to work out those distances and, on detecting the mods, use MM patches to scale the costs and capabilities accordingly. The cost modifiers in the configuration files are esoteric but understandable.
  20. They wanted me to build them a bionic author ... so I took their blutonium and, in turn, gave them a shoddy android casing full of used pinball machine parts ....
  21. If you have two command pods, you need to run each experiment, collect the data, and store that data twice--once for each command pod. If you are not finding the results in one, check the other. Transmitting data works best for situations when you need the science points right away or you want to try to squeeze a few extra points out of a single module that you will also later recover; it's always better to recover, in the long term.
  22. There's ... possibly a mod for that. There was a mod-in-development at one point, hight KerpocalypseNow, that modelled impact craters and terrain damage; the dev mentioned wanting to include some kind of terraforming after the destructive part was done. All I ever saw was an in-development preview, and that on another site, so I'll refrain from linking to it, but the important part is that dynamic terrain modification is possible and was at one point actively developed by the community. Whether that developer wishes to continue working on the mod is an open question; the information is nearly a year old. You should talk to the Kopernicus people, specifically @Thomas P., about this. They know more than most about how to tickle planetary surfaces into surprising shapes, and given how much of that information loads on demand, if there's an easy way to make on-the-fly alterations, they'd be the ones to tell you what it is.
  23. You can have as many identical copies of an experiment as you have experiment pods on the ship, plus one copy for each command module (you'll have to work out for yourself whether this requires you to take a scientist to rest said experiments). However, you cannot store multiple identical copies of an experiment in a single command module. For example, let's say you take two Goo pods and a lander can to the Mun and land in the Midlands. You can take and store one copy in your lander can, if you have a scientist you can rest and take another copy that stays in that Goo pod, and take a third copy that stays in the other Goo pod. You cannot bring those pod-bound copies into the lander can, though, because it will dump extra copies of the result--the extra results must stay in the Goo pods, which means that you cannot run those Goo pods again until you can transmit, transfer, recover, or reset those results. Practically speaking, this means that while you can get all the practicable science out of a single run with this design, you are limited to only one run at a time: after every hop, you have to remove the data to wherever it will be used and reset the experiment. I can think of three ways to carry multiple identical science results that also let you reset the experiment and use a biome hopper. You can take multiple command pods. This has the advantage of letting you keep the repeated results separate. You can take a Mobile Processing Lab. Labs can hold multiple copies of a result, though they can only process one into data. Of course, since they can also reset experiments, if you have one of these then you can use one of each experiment module and just run-and-reset as many times as you need. You can take an EVA kerbal. They can also carry multiple copies of results (that's why you get the dump warning when you try to board a command module with multiples, not when you take the extra copy from the experiment). Command chairs don't store science; it stays with the kerbal. Slap a command chair onto your lander and go crazy.
  24. It seems as though you don't have any real flaws in your design or your capabilities; you just committed a pilot error. It happens. If you've trimmed your fuel margins so that you have to do a suicide burn, then that's a problem with the safety factor, but otherwise, I don't see anything wrong. At the very least, you had to be close to a safe velocity; part of your ship survived. The nice thing about it is that if you know the ship is capable but you simply had a bad landing, you can send the same ship (plus a probe core, and check to make sure there are no crew!) to perform the rescue. Of course, any as-yet-untested flaws in the return stage will still be there if you use the same ship. The first time I did a rescue, I didn't find out until I made Mun orbit that I lacked enough dV to get back to Kerbin, so I had to send a third ship. That blasted rescue ship sat in Mun orbit for the rest of the save, mocking me with its empty, soulless abyss of a fuel tank. *Twitch*
  25. There's no advice I can give you that hasn't already been given, but I did want to throw some support your way anyway. Self-taught orbital dynamics is a very ambitious goal, and you've managed quite a lot: that list of accomplishments is something to be proud of. We also spent a lot of launches and a lot of money in real life to figure out how to get people to orbit and back, and so long as your program still has Funds to launch things into space, you're not losing the game, which means you still have the means to accomplish all those other goals. Yes, your rockets are entirely too expensive, but you learned something, as well, so--especially given that the money's imaginary--that's not bad. My first munshot cost 2 million, and I thought it was a bargain because Apollo 11 cost about 350 million--obviously, I forgot that Funds are extremely strong against the 1969 dollar.
×
×
  • Create New...