Jump to content


  • Posts

  • Joined

  • Last visited


1,452 Excellent


Profile Information

  • About me
    Rocket Scientist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 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 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.
  • Create New...