WarriorSabe

While this is true, and in fact there's good reason to believe such a thing to be impossible (at least with anything like normal matter), there is actually a workaround. If you design your drive right, you won't even *need* the mirror - there's a conceppt out there called laser-core antimatter (LCAM for short), that uses an immense z-pinch initiated by both electrons and positrons to compress the proton-antiproton reaction to a degenerate state (not quite as hard as you might think since they attract each other, but still pretty tricky), which then forbids annihilation modes that don't produce gamma rays. It is thought that it would actually function as a lasing medium in that state, producing a gamma ray laser beam, and given a seed laser to guide it, would not need any mirrors or anything as it's already a tight beam. However, the drive would likely still use a huge amount of power to run the z-pinch (which actually would require small particle accelerators, though something like a small wakefield accelerator could probably do it without being all that big), as well as the massive magnets and seed laser (which only serves to initiate lasing properly, and so doesn't need to be too big either), and you'd likely not really be able to harness the antimatter reaction for that power since it's basically 100% going out the back.

Well, LCAM is still the peak of antimatter drive tech, and a component of the most powerful propulsion technology possible beyond antimatter, the sphaleronic ramlaser (which is an amazingly epic drive, but also one that's both pretty overpowered for ksp and probably only possible to build in sizes well beyond what really works for ksp); but I understand why you'd want to skip it on its own, it is pretty low thrust. Though, not necessarily *as* low as you might think - because the thing is, it's so efficient it ends up having less waste heat again, as practically all the energy of the drive becomes a collimated laser beam, so you only have the waste heat of the ambiplasma confinement magnets, relativistic ambicurrent generation linacs, and anything absorbed from nondegenerate sidereactions (which is a lot of sources, but all relatively small compared to the main drive output if it's built properly), so when you look at the ratio of thrust to heat generation (the thrust stat that matters for high-energy drives, as radiator mass tends to easily outstrip drive mass) it's actually not any worse than BCAM, and has at least the potential to be better (it has a theoretical optimum of 100% efficiency, meaning a perfect one needs no radiators at all allowing you to cram hilarious amounts of power into it) Of course, BCAM is still a pretty low target compared to thermal rockets and the like, but like many other propulsion techs you can make the LCAM into a sort of one by injecting neutral hydrogen into the gamma ray laser output, and still see an improvement over BCAM since the reaction is performed more efficiently. The massively energetic gamma rays might even be able to heat it to protium fusion temperatures with enough magnozzle confinement (could easily do more traditional fusion fuels) for more afterburning (which'd also have the side effect of increasing molecular weight, further helping the Isp to thrust trade). Just some food for thought on ways to adapt LCAM into the core of a more punchy drive Well, here's the Atomic Rockets page on it: https://projectrho.com/public_html/rocket/enginelist2.php#id--Nuclear_Thermal--Fission_Fragment_Type--Antimatter-Driven_Sail

Plasma core at least still feels like a decent use for it, and there is also the ultimate antimatter option of laser core too that I've only seen in KSPIE before. There's also things like antimatter catalyzed fission sails, and (relatively) dead simple positron ablative engines. There's a pretty good variety of uses for antimatter out there, really

Gas core antimatter? That feels a bit like a waste of antimatter to me, seeing as such engines are limited by their material properties and so nuclear can match it in performance with just regular old uranium. At least it's not SCAM, though

Alright, version 0.22 is out now; full changelog is on the Github Sorry about the unreasonably long delay, IRL stuff and a lull in motivation meant I forgot to check back here. The logs tell me the issue's with Acheron not loading, which coupled with the folders I see it list, suggests to me that Kopernicus Expansion was incorrectly installed - the folder you put in the gamedata should be called KopernicusExpansion, so that may be a part of your issue. Actually with planet mods, oftentimes the Kopernicus.log and relevant .body.log are more helpful; there should be a zip file in KerbalSpaceProgram/Logs that has everything needed. In this case, though, I'm pretty sure the issue is with KopEx

I have a somewhat unusual question here: how might I set up a waterfall controller to read from a systemheat radiator? Ideally from its loop temperature , the way the heat animator does. The documentation in the wiki wasn't helpful in that regard, so I tried reading the source on the github to figure out how I might do it that way, but had trouble finding everything I needed, and ultimately couldn't figure it out that way either (I gathered it'd probably have something to do with the custom push controller, but found nothing I could use to figure out how to use that controller) If it comes down to needing to make a .dll I'm not entirely against the idea, but ultimately my question still applies there for the same reasons of being unable to fully figure out how its controller code works

Any updates on the status of this? I was just recently reminded of this, but don't see much activity on the github

Oh wow, one of the big things that's kept me away from Principia despite my love of low-energy trajectories has always been in the UI and the difficulty of planning, but now, looking at the changelog, this new update is exactly what I needed - whenever I try to visualize the physics in my head, it's always in that new frame and in the context of equipotential surfaces, so I bet that'll be the final piece that'll finally make the interface intuitive enough for me to be able to effectively use it for the ultrafine maneuvers I'm used to doing with my particular gameplay style. I was originally just planning on grabbing it to retest my system's stability since it's changed a fair bit since the last test, but I might just have to actually play with it a bit now that it's got that. As long as my computer can handle it, at least (and I tend to have a pretty generous perception of "handling it")

I believe there's wormhole support in this mod if you have kopernicus expansion, that could help a lot. You could also try a different warp drive mod like blueshift if the USI one is too slow, they might be faster. Or even simply go the old fashioned way and use better timewarp to pass the time quicker (I'm guessing both from your comment and from how they're likely programmed that you can't timewarp with warp drives, but I've not actually used any of those mods)

Shouldn't this be toggleable? Oftentimes I'll still want to see what it would take even if my current vessel can't so I know what it needs, and sometimes I'll have things set up in a way that would preclude the game being able to know my performance ahead of time (e.g., multiple engines of different types that I toggle between for different parts of the maneuver, parts dropped that aren't simply tanks, etc.). Also the simple fact that if some bug comes up that causes a miscalculation of dV (like happens all the time in 1) you may be locked out of accurate maneuver nodes

They're mostly various homeworlds from the projects of many of the creators. I don't think they're all released yet, but of the ones I know that are, - The big vacuum one on the left and the topmost world in front are Mesbin and Kerbmun from Whirligig World - To the left of Duna is Asite Par from the last one, Week World Planet Jam - Between Duna and Kerbin is, well, also Kerbin, from Alternis Kerbol Rekerjiggered (I'm not 100% sure if this works in the latest version) - To the top right of the big desert one is Haven, from Edge of Eternity (which is still well in development, like 60% of the worlds still have placeholder assets) - To the left of the one in the bottom right corner is Echo, from SLIPPIST-1 (which like AKR I'm not sure if it works in the latest version or not) I also feel like at least one one (maybe more idk) of the rest of those is released but off the top of my head I can't pin down which

Having Unity versions is definitely a good thing to have for all those compatibility reasons you mentioned, but also, Scatterer flares are generally overall more capable (unless you want a very large number of ghosts), so perhaps having both options would be a good idea? It's not just the being compatible with the atmospheric extinction, but also the fact that every component can have independent scale curves as well as intensity curves. For an example from Edge of Eternity, while I chose something which probably doesn't have the same overall design direction in its particular assets, For context, the first picture is out at Esker, the next planet away from the homeworld, while the second picture is Calefact, the innermost planet 6 orbits down where the sunlight is so intense the kerbal standing there has less than a minute before needing to go back in the ship to avoid overheating and getting poofed. Obviously EoE's flares are a lot simpler than yours, but that just means that you could benefit a lot more greatly from those features than I am here.

While I've yet to personally play 2, from everything I've seen from those who have, this all makes a whole lot of sense. Modding after all works best when there's 1) actual direct support for it and 2) a game that actually functions properly, so those should definitely be priorities (and even just from modding KSP1 I've been running into issues caused by the shortcomings with both, I'm looking at you infinite-distance directional sunlight)

I think those ended up becoming a part of a separate mod under her own direct authorship, iirc

Actually, I can run EVE volumetrics just fine on low settings but am far below the minimum spec for KSP 2 with my MX-150

While I am currently out of town and don't have access to my computer to properly check and cross-reference the logs, I do know that when originally uploading the last update the files were incorrectly uploaded and I had to immediately upload a patch with the correct files (twice, actually), which brings me to two questions: did you make sure you downloaded the latest version, and if so, does redownloading a version before the last major one work?

They do, however, include biome names and occasionally notes in comments, which in some cases could be spoilery

Generally yes, those are the files you want, but I do have some experience with using that tool, and it's very particular about how it expects the configs are internally formatted, and I fully expect it to not understand the PJ2 configs - specifically, the masses, reference bodies, and semimajor axes of the planets. That meaning, they will upload, but the distances and some masses will be wrong, and a lot won't be able to find the object they're supposed to orbit and not show up on the map (they'll go to into their own holding area at the bottom of the list until they have a valid reference body) The reason why being, for the planet smas and for a number of their masses, instead of directly setting them these configs take a base value and multiplies them, mostly as a result of how the jam was structured. For the reference bodies, the reason is because they're keyed to identifier rather than name. So if you want to upload the configs, you'll need to manually set all those to the correct values after uploading, which would also mean reading the configs and very easily accidentally exposing yourself to spoilers (as well as also just being a lot of work). For that reason, I might recommend trying KSPTOT - while it's overall a less convenient tool to use and doesn't always get as efficient of trajectories, it works by using a small mod that links to it and reads the planets directly rom how they're loaded in the game, therefore bypassing any potential confusing configs. It does need to be downloaded and run separately from the game and requires external libraries (MATLAB) to be installed, however. You could also always try doing it manually, but if you're new to gravity assists PJ2 isn't exactly the easiest place to learn how to do them manually (though they are incredibly powerful).

Yeah, as far as I know the mx150 is fairly comparable to the 1030 (it might be somewhat worse due to being optimized for a laptop). And yeah that was about what I got, 15-25, no parallax and all at default settings (so it may have been better with lower settings, but possibly worse with also parallax) - but I would add, those of us on cards like that are likely to kinda be used to framerates like that already (and the motion artifacts do go away when paused or simply not moving too fast so you can at least still get decent screenshots), and that test may have been further slowed down by external factors since the framerate was slightly lower in space far away from the volumetrics too. Basically the final "what it came down to" of that test is on my laptop with a 2gb MX150 (also GDDR5) it was about a 30-40% reduction to framerate compared to the basic EVE redux, depending on whether you consider the high space fps reduction to have been evidence of an external factor to the slowdown or not.

Best I can think of would be removing the layer2D, but that would also remove them in-flight from orbit

When I made the map, the way I handled the ascent was to treat gravity losses as cosine losses (which works for a horizontal ascent profile), and integrate them over the decreasing effective gravity as orbital velocity is approached, using some ballparks for typical TWR values. For drag losses on atmospheric worlds, I have a more empirical polytropic fit based on what seemed to be typical values for various reference worlds (as well a similarly empirically determined factor that increases gravity losses to account for less horizontal profiles), and calibrated to return values similar to those on the stock map, since I figured players would most likely already be familiar with adjusting those values to their own rockets and profiles. For transfers, you are right in that I used higher orbits, typically 5-10km above obstacles or atmosphere, except for the very smallest worlds. I also modeled the orbits as circular, with the exception of Esker, for which I used Transfer Window Planner (and I plan on ultimately using such empirical values for the remaining irregular orbits). And, on the subject of Esker, that's the one case where your low-end value will likely not be quite achievable - it's in a 2:3 resonance with Haven, which means it always is in the same alignments, and will never allow you to transfer towards periapsis. It also turns out, according to TWP, that despite having only a single point of conjunction, there are actually two alternating transfer windows per synodic period pretty with similar costs, one of which is quite unusual (it happens around conjunction, with the ejection from Haven being approximately radial out from Terminus). All the other eccentric resonances are higher order, though, so they should allow decently close to a periapsis-aligned transfer at the least. And I guess if you're willing to wait taking several orbits to get there you could try launching to its periapsis, you just might be sitting around Terminus for quite a while before things finally line up. That said, good work on the table, it's something I had thought about making but ultimately ended up not. I'm surprised you even went so far as to include all the Cerberan moonlets, that's a lot of extra transfers to calculate considering their less significant role.

Wait, that's a potato? Then what is my 8 gigs, I5 CPU, and 1030-equivalent considered? (which with nothing else on default settings gets a pretty solid 15-20 fps with the new volumetrics, yet to test with a bunch of mods)

Something like 60-70% of the framerate, on average. That's with the included configs and default settings, I'm sure better could be achieved by lowering the settings or using less intensive cloud configs

I'm not sure what kind of performance that has, but they work relatively fine on my laptop's MX 150. Framerate's kinda low with default settings but it was already kinda low so it's not a ton worse

Sometimes we like keeping those old monuments to the past. I remember doing a crewed landing on an asteroid moon I had visited 24 ingame years ago, and touching down within a kilometer or so of an old probe and paying it a visit on EVA, which was fun