Jump to content

Pds314

Members
  • Posts

    3,091
  • Joined

  • Last visited

Everything posted by Pds314

  1. I notice an odd difference between these missiles and the ones that come with BDA. In BDA, the missiles have this segment of code in the cfg. If I understand correctly, these are setting Bezier curves in Unity. Your missiles do not appear to have either of these curves. I don't know what exactly BDA does if they're not present. Assume some default value? I'm not 100% sure. I will investigate whether these missiles are indeed ever chasing flares, but I'm honestly not totally sure why they're more accurate most of the time than the default sidewinder, whether it's just that they have much better stats or they might not see flares correctly. EDIT: Tried pitting two He-162 clones against each other using the particularly anemic TY-90 missiles (The weight being set to the same as an AIM-9 when in reality it's 30% that much doesn't help any in their being anemic, and nor does the fact I'm using them against airplanes rather than helicopters). The flares definitely work against them. I don't know exactly what BDA is doing WRT flare detection in these missiles but these missiles do actually know flares exist. Of course, in this situation the flares are basically 100% effective. Althogh if you remove them, the missiles become pretty lethal. Even the really anemic ones like MICA, TY-90, and PL-8. lockedSensorFOVBias { // floatcurve to define how the missile weights targets and flares off the center of where the seeker is looking // is only active once the missile has locked onto a target // should be set from 0 (seeker is looking directly at target/flare) to at least lockedSensorFOV/2 (target/flare is on edge of sensor FOV) // it is recommended that the value at 0 be set to 1.0 and max value set to 0. Here is an example of an effective flare rejection curve: // key = angle off seeker centerline weighting bias // key = 0.0 1 // Highest weighing on centerline // key = 3 0.83 // 17% lower weighting at edge of sensor FOV // key = 10 0.25 // Beyond Sidewinder FOV, provided for example purposes for large sensor FOV missiles // key = 30 0.1 // // key = 90 0.0 // Beyond 90 flare/target is behind missile // This set up will maxmize flare effectiviness: // key = 0.0 1 // key = 90 1 // This is the current default curve (same as 1.4.0.7 BDAc Sidewinder): key = 0 1 0 0 key = 0.6 0.993333333333333 -0.0222222222222222 -0.0222222222222222 key = 1.2 0.973333333333333 -0.0444444444444444 -0.0444444444444444 key = 1.8 0.94 -0.0666666666666667 -0.0666666666666667 key = 2.4 0.893333333333333 -0.0888888888888889 -0.0888888888888889 key = 3 0.833333333333333 -0.111111111111111 -0.111111111111111 // For other missiles it will scale from 0 to lockedSensorFOV/2 instead of 0 to 3 (3 = lockedSensorFOV/2 for Sidewinder) } lockedSensorVelocityBias { // floatcurve to define how the missile weights targets and flares based on the angle between their velocity vectors // is only active once the missile has locked onto a target // should be set from 0 (tracked target and flare/alternate target have aligned velocity vectors) // to an angle less than 180 (tracked target and flare/alternate target travelling in opposite directions) // it is recommended that the value at 0 be set to 1.0 and max key value be 0. Here is an example of an effective flare rejection curve: // key = angle between velocities weighting bias // key = 0.0 1 // Highest weighing for target/flare travelling in same direction as tracked target // key = 3.0 0.83 // // key = 10 0.25 // // key = 30 0.1 // // key = 90 0.0 // ignore flares travelling perpendicular to target or in opposite direction // This set up will maxmize flare effectiviness: // key = 0.0 1 // key = 180 1 // This is the current default curve (same as 1.4.0.7 BDAc Sidewinder): key = 0.0 1 key = 180 1 }
  2. Maybe manipulating the the loaded vessel position relative to the root part of multiple crafts to physics unload unnecessary components of the machine in separate crafts could extend the possibilities? No need to completely unload them. Just make it so the game isn't spending lots of effort calculating physics for, say, a block of RAM that's currently not in use. It will still render it but it won't need to do physics for it.
  3. Thinking big here, one of the concerns I've having is just how truly terrible the part count will be. I doubt practical, addressible RAM can be under 10 parts per bit, with multiple of them being engines or something. I originally thought it might be possible to do something like an 8 bit CPU because this stuff would be pretty simple to actually copy and paste all over in the editor and implement pretty sophisticated computer architecture that way. But I'm thinking that would be >10000 parts or some nonsense. Needless to say, that might work with Minecraft but not so much here. I think in terms of practical CPUs, saying we're gonna need it to be a RISC machine is an extreme understatement. I'm not even sure a well-fleshed out 4-bit machine is doable.
  4. hmm... RS NOR could be made with a hinge and two continually running Junos as input wires, and a third which the hinge conditionally blocks as an output wire. Inverted output could be a fourth Juno. Wire multiplexing and repeaters can be achieved by using one Juno to unblock an array of Junos all at once with a plate or comb structure, with the mechanism springloaded by the strength of the hinge to go back to normal if the input gets blocked. An AND gate can be made using two hinges or pistons to block a Juno and then having two blockable input Junos. A NOT gate would just be a Juno that blocks another Juno using a springloaded hinge. Two of these could also be used to make a latch. An OR gate would be pretty trivial. Two Junos facing at the same springloaded piston/hinge and a third that is unblocked when force is applied. There could be multiple types of more and less precise clocks, from servos that periodically block Junos, to KALs and more, with a NOT gate feeding into itself (think a sprinkler blocking mechanism) or a trio of NOT Gates in a loop also being an option. One issue I can see is that the write wire for RAM would either need an awful lot of wire multiplexing or a more complicated mechanism so that only the active address can block the beam and then you only need a repeater once every 10 meters. One solution I can think of is to do ram writes the same way as multiplexers. Right, have a bunch of / all of the addresses all open at once and only the one that the addressing logic picks gets written to. Basically using a big shield thing to stop the RAM from being written while the addressing logic is being set. Now, as to RAM addressing logic itself, this is a bit tricky. We want basically want each bit of the address to eliminate half the possibilities leaving only one left. I would argue that the easiest way to do this is to push a bunch of increasingly stretched out checkerboard-shaped blockers out of the way. The first being one address wide per checkers square, the second being 2, the third being 4, the fourth being 8, then 16, 32, etc. There would be a tradeoff here in terms of speed and complexity vs address size. Very deep checkerboard blockers would take longer to move up and down or rotate out of the way, so it probably pays to make your ram somewhat compact. Also you probably want to put the blowers for the addressing system near the middle of the RAM for stability. One really nice feature of all this is that because engine thrust rays are noncolliding, overlapping wires is trivially easy. This might be good for displays, ribbon cables, GPUs, etc. Now that I think about it some more, if you use cheats, then it might generally be better to use the smallest rockets you can rather than a big bulky Juno except in applications where high thrust is needed to quickly move something bulky. And KAL overclocking can actually fix the thrust issue. So maybe ant engines or something set to infinite fuel are preferable to Junos. If we want a design that works in zero G, one option would be to use two springloaded NOT gates as the basis for the latch. If we want a design which can operate under acceleration or rotation, then making stronger springloading force and very light blockers might help. In principle, I don't see any particular limit on the G tolerance in any given direction that a NOT gate can take. In terms of constructing other gates, a compact XOR gate might be able to be made using a servo and two engines coming from input wires, with a third engine in the middle. The servo would be springloaded to go toward the middle, blocking the thrust from the third engine, and if both or neither input wire is active, would stay there. Otherwise, it would move to one side, allowing the thrust from that engine to go through. One issue here is that the timing of the two inputs needs to be perfect or it will create a short pulse when switching from neither to both. But that's pretty much true of all XOR gate designs because that's an intended behavior of XOR gates. If you want to clean up the signal or add a deliberate delay, one option would be to have low power engines, heavy blockers, a long travel distance, and light springloading on a repeater. This will basically average out the signal over a longer period so it can ignore short on/off pulses.
  5. The aim of this challenge is to build a craft that can go as fast as possible on the surface of the water, by pushing off the water itself. You may use any propulsion technique you wish, provided that it is hydrodynamic and not aerodynamic or (directly) thruster-propelled in nature. You may use DLC and informational or piloting mods. However, physics mods must not be enabled, even if you don't think they do anything, as water doesn't respond well to many of them. Also no mod parts because they're not balanced.
  6. I would say not, as it pretty clearly provides an unfair advantage as per rule 3.
  7. Is there a requirement that the spaceplane be able to land afterwards?
  8. Yes. DLC props are allowed. Mining on the runway? Hmm. I think not. You should at least need to pay for the fuel you use on Kerbin and I don't want this to become a "who can spam 10000 parts that will never fly?" challenge. No mining on Kerbin or starting with ore.
  9. Mission The aim of this mission is pretty simple, on paper anyway. Get a Kerbal to Eve and let them swim in the deliciously purple but probably not very delicious ocean covering much of its surface, then get them back alive, as cheaply as you can and by the earliest possible ingame date Start a new sandbox save (I would recommend sandbox at least, but do career if you're a masochist I guess) and get a Kerbal to Eve. They must actually swim in Eve's oceans, so that's probably where you should land them. Then return that Kerbal to the surface of Kerbin alive. Scoring Score = ingame time in days^3 * total mission cost / 10^12 LOWER is better. Thus, if it costs you 1,000,000, and it takes you 500 days, You'd get a score of 125000.. Reducing it to 400 days would be worth a score of 64000. Reducing the cost to 200,000 will improve the score to 12800. Recovery: the recovery rules are simple. If it's on the surface of Kerbin and in direct line of site of any KSC building, it is considered fully recoverable. Else, it's considered fully non-recoverable. Rules 0. At least one Kerbal must actually swim on Eve. Not just walk. Swim. 1. No aero exploits of any kind. Regular aero optimization is encouraged. 2. No perpetual motion devices / kraken drives. 3. No mods that provide an unfair advantage. 4. No debug cheats. 5. ISRU is allowed, so stripmine Gilly by all means, but this is KSP, not interplanetary oil company simulator 2021. If deemed to be a significant factor, mined or processed resources will not be included in your recoveries. Additionally, ISRU will be prohibited on Kerbin's surface in order to prevent abuse, as will pre-loading the craft with ore. 6. No stranding or killing Kerbals. All Kerbals must reach home for the mission to be considered a success. 7. Kerbals don't need to be in pods. If they get back legitimately, I don't care what, if anything, they are riding on. 8. Pre-1.12 missions shouldn't exploit things that were since fixed like ladders making Kerbals massless. If your mission would not be possible in 1.12 it will be rejected. Strategy The first day is on the tail end of a launch window so you should probably start your journey to Eve pretty quick and whatever you do in terms of orbital construction or refueling better be worth it. It will almost definitely be worth recovering your launch vehicle though so you should probably build it to be recoverable in stock KSP. However, those who do launch early will find the options for getting back much less inviting. So either delaying the return launch or using quite enormous amounts of Delta-V will be likely necessary. However, Kerbals are pretty light and you can get a lot of Delta V when that's all you need to get back to Kerbin. Keep in mind if you plan on using ISRU that you don't really have unlimited time within the Evean system, so you want to mine and convert quickly. Also keep in mind that you can't make Xenon from ore. It turns out that recovering heavy nuclear stages from crazy hyperbolic trajectories is kinda hard, but not recovering them is kinda expensive. Who would've guessed? Don't get so committed to optimizing time that you forget completely about cost. Cutting time may be worth more, but it is vastly easier to cut cost than to cut time. Oh, and remember, it's ingame time from the beginning of the world, not mission time. Launching late won't help you.
  10. Sure. The one thing I will say is that electric designs don't fit the spirit of the challenge so I will be more impressed if it uses turboshaft propulsion using blower engines.
  11. I like the idea although it sounds hard to fly because you're gonna need to do a Tylo landing while you burn to orbit. I guess if you just set it on its course and focus on the landing it wouldn't be *that* bad? Also won't it need a relay if comm network is on? I guess I could put one on whatever transfer stage brought me there though. In any case, I almost wonder if having the lower stage do the Tylo landing itself and then burn back to orbit would work better. Sure, that means the lower stage needs more Delta-V, but it's not carrying a payload with most of that Delta-V. It would be heavier but vastly simpler to execute. EDIT: from a mass perspective, it's quite clearly a losing battle. Like, not even close. Even with my 6-Kerbal, 1-tonne reentry vehicle on there the mass difference between the two is impressive, and it's not even 15% lighter than a single stage design. Also not sure the viability of 3800 / stage. Even if I accept 2250 as achievable, which with my TWR I doubt it, 800 will just about get out of Tylo SOI. It takes 890 in a single burn to leave Jool SOI and a full 1090 if I do a single burn to get back to Kerbin. So... the idea of a 5300 Delta-V trip from Tylo orbit to Tylo surface to Tylo orbit to Kerbin, by any method, does not look realistic to me. More like 5600 with a TWR in line with Camacju's idea or somewhere around 6000 with minimal TWR. So far, if I stick a perfect landing, and I mean I run out of vertical and horizontal velocity simultaneously at ground level, I can 2550 on the way down. I think the big Delta-V killer is that I'm having about 37 or 38 degrees of cosine losses for a lot of descent. But currently, yeah, 10 km orbit to ground to 25 km orbit costs me a total of 4950 DV. And while 950 might be enough to get back to Kerbin, it's definitely not enough without gravity assists somewhere in there, either from other Joolian moons or Dres or Duna or something. So I think 5900 is actually too little DV for a starting TWR of 0.7.
  12. *Proceeds to spend 2750 m/s just to land.... Managed to optimize it down to 2550 but still... low TWR landings are not easy lol
  13. Hmm... How hard would full reuseability be? Without nukes, jets and ions it could be very very tough I think. Delta V to go from suborbital Tylo to the ground back to orbit and back to Kerbin isn't small.
  14. Yes, but the rocket will be occupied for far longer even under the most optimistic assumptions. It will take minutes to board and deboard, potentially multiple hours to fuel unless that can be dramatically accelerated, and will need safety checks of at least some sort after every flight to make sure it's still spaceworthy. These things cannot necessarily happen simultaneously either. Checking a rocket for signs of non-spaceworthiness while it's being fueled is not super easy to do, and having the passengers within a kilometer radius while it's being fueled isn't the safest thing either. If you actually have anything that needs to be maintained between flights, you also need to do that. So there will be a lot of people waiting for some stage of this process to complete while other people are waiting on a half hour boat ride after going through security for half an hour. I think you'd be very, very lucky if the flight took under 3 hours from the passenger's POV and that's if everything is timed perfectly. And from the rocket's POV, which, you know, is the actual investment here so any time it's not in flight is not good for business, I think it could be sitting on the pad for 90% of the time if not more during the smoothest of operations. Compared to maybe 10% for a transonic airliner flying intercontinental or ~25% for a supersonic one. I don't think it's necessarily impossible but you need a rocket that can deboard almost instantly and reboard almost instantly, as well as needing essentially no regular maintainance between flights and being able to fuel in minutes instead of hours. It needs to be both far safer than hitherto existing designs because people do actually factor safety or lack thereof into their travel plans. There needs to be a way for it to land directly onto the pad it will take off from and there needs to be infrastructure to actually get people to the rocket very fast after it's fueled and such, keeping in mind this is likely to be some very large distance. Like 10+ km minimum because, guess what, spaceports both land and sea make bad neighbors. Bad enough that they might even be built in international waters. Which also "solves" the aforementioned regulation issue at least to some extent. However, it would still be well within the EEZ of the host country so it would still be subject to some regulations and couldn't be set up legally by a foreign power. So your options to get there are basically: 1. Make a boat. Cheap but very slow to go 20 km or so each way. Passengers might just prefer to take an airliner. Might be faster if it's some kind of really fast boat. 2. Make a train. Problematic on water, especially since not transatlantic but transpacific flights would be pretty much the ideal region from an economic standpoint, and giant earthquakes and giant floating or underwater railways don't mix too well. 3. Make a plane. Well... it's fast. You need a landing strip at sea and I question why you don't just fly the whole way, but I guess you could. 4. Put the spaceport on land, but clear a city-sized area around it and then use a train. Not really an option if you want the rocket to land near inhabited areas unless they're landing in a desert or something. But maybe you can fly Salt Lake City to Tashkent? Well, if you land in Kazakhstan and cross the border anyway. Plus, more ways to dodge regulation since those are no longer part of one country since the 90s.
  15. Yeah I was thinking rotating the alignment. Not docking port Kraken. That's even more of an abomination than I want.
  16. point to point transport on Earth ends up competing with subsonic airlines. Fuel economy wise, that's a losing battle. It's not as bad as some people seem to suggest but pretty much you'll struggle to get better fuel economy per passenger km than the Concorde (I'm not counting oxidizer either, but it is pretty cheap). Also I think there's a safety issue. A launcher with a life expectancy of 10000 flights and a 0.005% catastrophic failure rate would still be far behind commercial aviation in safety and cost, and the rigors of near-orbital flight are quite a bit more violent (>2.5 G vs <1.5 G) and inherently less safe than an airline flight (cabin depressurization on a spaceship is harder to deal with, you can't just pump pure oxygen into an unpressurized mask and call it good, and indeed, can't safely expose even the skin to the outside pressure, let alone the lungs, ballistic landing requires engine power and fuel while aerodynamic landing doesn't, rockets have a 20-50% margin of safety while airliner aircraft often have >100%, loss of attitude control during reentry is significantly more dangerous than in subsonic cruise flight over land with adequate fuel to recover). So even if we had a rocket with only a 1 in 20000 fatality rate, so 1 fatality per ~200,000,000 passenger km or so, that's a bit safer than car travel but only a bit. From the passenger point of view, we can think of there being three sources of "cost." 1. The time the flight and surrounding activities take, including getting through security, secondary transportation, boarding, booking the trip, launch delays, etc. There would be a novelty factor of incidental space tourism but this would likely wear off pretty fast. 2. The average quality adjusted life year of injuries or deaths from a flight. 3. The ticket price of the flight in time spent doing work at low quality of life, or opportunity cost of what they could spend that money on and get higher quality of life. So: 1. Fairly short flight times (less than an hour for sure) would come with considerable transit and security time. Especially if you don't live near a spaceport or are not going to one. Land requirements for a space port may be even higher than those of an airport because of noise pollution. I would say at least an hour of overall security, and depending on safety features, maybe even an hour of boarding and deboarding. Probably a couple hours of secondary transportation. We're probably talking 5 hours minimum trip time. 2. Even with our 2 order of magnitude hypothetical improvement in safety, losing on average 1/20000th of your remaining life is not an insignificant safety concern. If the average person has 40 years of remaining life expectancy, that's about 17.5 hours. Obviously if it's more in line with modern risk levels, the expectation would be closer to 1750 hours. 3. Ticket price. This one varies considerably by country and income level but you had to spend time to Earn money buy the ticket. Fuel alone would probably be like ~2000 liters per person per trip, each of which is around $1 or maybe $2-3 if it's expensive fuel. Right, that works out to 100 people burning ~200 tonnes of fuel or 600 people burning 1200 tonnes. I think you'd be hard-pressed to fit many more than that many people on a ship that size. We also mentioned that ships are retired after 10000 flights. So if each ship costs about $500000 per seat, in line with subsonic airliner costs which is probably very optimistic, that's $50 extra per ticket for the cost of the ship itself. If the ship is 10x the price, that would be $500 a seat. ROI is another factor to consider. If a ship can average 6 flights a day, that will be retired in about 5 years. If it can only make 8 flights a month, then that's gonna take about a century to retire meaning it's actually overly reuseable. If we assume the spaceline wants a 10 year ROI, then anything under 3 flights a day and we start having to add a very large markup to the ticket cost. If you can only do 1 flight a day, then you're only reusing it 3652 times in that 10 year period. So more like $150-1500 per flight. Finally, we have maintainance costs. These things operate with thin margins of safety so presumeably a lot of things will need to be maintained. Current estimates are 0.4-10% total relaunch costs for boosters. If we take the optimistic side of that, assume half is maintainance, then cut it by a factor of 10, that's still twice the cost of the vehicle in maintainance over it's lifetime. So that's around $100-1000 per ticket going to maintainance. Add in a healthy margin to further development, subsidize other projects, buy more and/or make the person owning this operation richer than god, and I think we can see a scenario where even an "ultra-reuseable" vehicle could have a $10000 price tag on one flight, but I could also see as low as $3000 if we're very optimistic. Either of those is hundreds of hours of first world median wage, suggesting that perhaps fuel costs would be the primary determinant of mass adoption. That being said, the same does not apply to weakly or moderately reuseable craft. If you have 500 launches per ship, 0.1% mortality, and 50 launches a year, and 0.4% maintainance costs, your fuel cost will still be $2000-6000/head, but your fixed capital cost will be $1000-10000/head, and your maintainance cost $2000-20000/head. Add in a few thousand for the company and you have maybe $8000-50000 ticket price. Reasonably economical space tourism but not competitive with any kind of airline. Overall, I think we're still kind of in the range where 50 flight reuseability, 20 flights a year, 0.5% maintainance costs per flight would be considered very good. And thus, spaceliners are not yet viable for mass market.
  17. Nope. It's way too good of a part. Mk1 Cupola, Mk1 cockpit (not inline) or the Mk3 cockpit are allowed. There's kind of a trade-off between Mk1 cockpit's weight and Cupola's cost and shape.
  18. Hmm... Apparently because of the small tower, it actually misses a lot if the carrier is moving. 22.3 m/s normal to the missile's attack vector was sufficient to cause a miss twice in a row from different angles and speeds. I doubt that applies to the slower more maneuverable missile but good to know that an aircraft carrier with the bridge sufficiently isolated can outright dodge a missile. I suspect the reason for this is the lack of an effective lead turn. So 3 seconds (2.4 km) out the missile is only turning 0.5 degrees a second. Not enough to compensate for the last 200 meters where it needs to then turn 4 degrees a second. The "correct" solution is to make it lead turn by having the angle of the missile lag even further behind the prograde vector, but this would reduce it's overall angular acceleration and possibly accuracy I think.
  19. Another carrier-killing missile. This one is not as agile so probably best not to use it on anything that can maneuver out of the way very well, but it is very fast and has very good range and is also an SSTO with fuel to spare, meaning you can probably use it as an ICBM if you don't want to immediately lock a target. I might install BDA for the vessel switcher or something to see if I can counter the missiles in some way, I kinda doubt hitting a missile nose on with another missile is doable but maybe since it's *exactly* nose-on and the missiles are anti-inertial it could work? Or perhaps taking an aircraft off from the carrier to hit the missile with a missile? If that fails, I guess just bombing whatever is about to fire the missile might work? And if that fails, maybe I can engineer defensive cannons to shoot the missile at the last second, or just use BDA CIWS to do it... though that actually might not cause it to miss as the kill range would be very short.
  20. Build a craft powered entirely by docking ports. You may use hinges and wheels and control surfaces that are not docking ports, but all power should come from rotating the alignment of the docking ports. Can you build a rover? Can you build a plane? Can you build a boat? Can you climb a mountain?
  21. Passenger cabins in general aren't allowed.
  22. So one thing here is rapid turnaround. At some point, you reach a tipping point in reuseability where making the thing be able to relaunch quickly becomes more important than making it able to launch efficiently. If an SSTO has twice the initial cost and size for the same payload, but the relaunch process is something that can be done in an afternoon, not multiple days, it might be worth being fuel inefficient to be able to just land at some nothing space port already under your flight path. Because the SSTO, while twice the price, pays for itself faster by launching multiple payloads a day vs multiple payloads a week and only from areas that have a spaceport that can mate the lower stage to the upper one. All of this of course assumes that this demand actually exists. Which could be a bit of an issue. People have a way of growing their appetite for something when it gets cheaper but I don't know how quickly people would think of, say, enough payload for a fleet of 100 launchers with 100 tonne capacity, going up and down 100 or even 1000 times a year. How many megatonnes a year of space launch capacity will we actually want in the reasonably foreseeable future? Anyone's guess. Even the lower end of that is pretty enormous by modern standards though. Basically a Saturn V launch an hour or to put it another way, 5 ISS's a day.
  23. The aim of this challenge is to get to your destination as cheaply as you can, using some of the worst parts the game has to offer. Craft restrictions: Liquid fuel engine allowed: LV-T45 Swivel: Yup. You get a gimballing LF engine. But it was that or give you access to the reliant which is basically better in every way other than having a gimbal. Vernor engine: this is the LF RCS thruster. Overweight and oversized but that's perfect. LV-1R Spider: A tiny, expensive, overweight engine that works poorly in vacuum and isn't aerodynamic? Yes please. Solid Fuel Boosters allowed: Flea: the first rocket you get in the game. Hammer: as Flea but slightly better. Separatron: This probably isn't meta. Launch Escape System: Fly Safe! Monoprop engine allowed: O-10 monoprop engine: Frankly this will probably not be meta even for this challenge. But hey it you think it's good, this is where it could shine. Note the absence of any normal RCS thrusters. Atmospheric engines allowed: Juno: It's tiny, inefficient, and expensive for it's size. Good luck. Goliath: Big, sorta expensive, and doesn't go very fast? It's perfect. Ion engines allowed: Dawn: It costs a fortune and even more to operate. I highly doubt It'll be meta. Breaking Ground Engines allowed: Both Turboshafts are allowed. Electric motors are not. Reaction Wheels allowed: Only command pod reaction wheels are allowed. No separate reaction wheels. Command Modules allowed: Mk2 drone core: expensive and awkward? yes please. RC-L01 remote Guidance Unit: Even more expensive. Cupola: very awkward. Mk1 cockpit (not inline): Heavy for a single seater. Mk3 cockpit: Oh? It's heat tolerant? It seats 4? Yeah I hope you like the cost, weight and size though. Passenger cabins are not allowed. All wings, control surfaces, structural parts, electrical, batteries, etc are allowed. Mission profiles: For all missions: Recovery is deducted from flight only if you land at the KSC or in view of it. No "recovering" mined resources or converted resources. Base score = 1 unless it's modified, and can't be negative. Final score = (cost - recovered) / base score. Lower final score is better. Stranded or killed Kerbals do not give you any base score, don't count towards mission completion requirements and reduce your base score by 1 per Kerbal stranded or killed. First orbit: put a command module in orbit. If crewed, bring it back from orbit safely. Keostationary satellite launch: Launch a probe core, a sufficient electrical power source, a stationkeeping system with at least 200 m/s of Delta V, and relay antenna sufficient to reach Kerbin's surface, to an approximate circular orbit with a sidereal orbital period of between 5:54 and 6:04. Mun sample return: Land on the Mun and return to Kerbin. +1 base score per additional landing and return from orbit. +1 base score per Kerbal landed. +1 base score if at least one Kerbal remains in Munar orbit throughout the mission. Duna rover landing: Launch a vehicle to Duna and reasonably prove that it could drive for at least 100 km after landing (you need not actually do so). +1 base score per additional rover. +1 per Kerbal who reaches low Duna orbit. +1 per Kerbal who reaches the ground. +1 per Kerbal who rides a rover. So sending one Kerbal to Duna to drive a car there and return gets you a base score of 4. Outer system exploration: Go to worlds beyond Duna's orbit.+1 for each additional flyby to a unique body closer than the radius of the object. +1 for each landing on a unique world. +1 for each Kerbal who witnesses at least one flyby. +1 for each Kerbal who lands at least once. +1 for each flyby and each landing with at least one Kerbal onboard. +1 for each Kerbal who is present for every single landing and flyby without exception.
  24. No KAL-1000 or no overclocking exploit? As in, are we allowed to do something like use a KAL-1000 for automated control?
  25. Taking out Jeb's plane without taking out the carrier. 10 km shot without ever going over 150 meters above datum. Full fire and forget functionality.
×
×
  • Create New...