HebaruSan

I'm sure some adaptations would be needed for space, but here's one way it's been done on Earth:

Is there a reason you don't want to run msbuild.exe? The csproj and sln files are basically recipes that tell msbuild.exe which csc.exe commands to run.

Supposedly there is a "UI/UX team", but they can't figure out very basic, glaringly obvious ideas like this (which I personally implemented in a KSP1 mod reflexively as soon as I realized I needed to display pending timespans—in fact you can see it in my many-years-old forum signature!) without user feedback? It's frustrating and begs for an explanation.

That's a heat shield fairing. (Part of that craft's mission was to test whether 1.25m heat shields can protect that lander can. It successfully demonstrated that they can't.) I can definitely believe that heat shields would obstruct fuel flow, which would leave the mystery of the aft thrusters. This isn't important enough to me to re-run the mission to check whether I'm misremembering about those.

I guess since you're saying this in front of a wider audience now, I can ask everyone else: Does anyone else actually feel this way? My initial reaction to the idea of a pop-up announcing some implementation details about how some third-party software (Steam) works was that it was something most users would neither care about nor understand, and they'd be annoyed that this irrelevance was being put in their face. And that how Steam works is not really CKAN's business or problem.

The aft thrusters are also attached below the decoupler (and work), so I think that possibility can be ruled out.

I tried them with my lander, with mixed results. Here are the fore and aft thrusters (composite screenshots so I could outline-highlight multiple parts): Those worked fine, but the lateral thrusters placed on the decoupler at the COM never worked, and I was not able to figure out why. Obstructed? Fuel-deprived? A bug? No idea. If anyone has tried a similar design and encountered and solved this issue, please reply.

Déjà vu! We did "3.3" once before: Previous report when the release came out: https://github.com/Angel-125/DSEV/issues/20 Trying again here in case it's more effective...

Thanks for the details, I see what's happening now! That URL handler thing does need admin access in some cases, which trips the admin user check incorrectly. Thanks for the report! I'll make a note to get this fixed in a future release. For now, you can say "No" if it asks you that again. The error is harmless, and probably nobody uses this URL functionality anyway.

I'm curious about this. Was it a popup from your browser, or Windows itself? This doesn't sound like something CKAN itself does. Sort of, yes. You shouldn't run CKAN as an administrator user, because it doesn't need that access to function, and there's always a risk in giving a program excessive privileges. This was something that CKAN has always checked on Linux, and the check was expanded to Windows platforms recently. Don't worry, plenty of folks have found it confusing so far. The best solution is to run CKAN as a non-administrator user, either by creating a new non-administrator user or removing administrator access from your usual user. If you really don't want to do either of those things, a workaround for experts is described here: https://github.com/KSP-CKAN/CKAN/issues/3956#issuecomment-1873016474 In fact, GalaxiesUnbound was on CKAN for a while, but was removed because its author changed his or her mind and requested for it to be removed. It had nothing to do with choosing configs. CKAN does not request admin authority, and you should not run CKAN as an administrator. Can you share a screenshot of what you're seeing? OK, I looked up the URL handler message, and found this: This isn't about admin access; it's just asking if you want it to register ckan:// URLs for your user. It should also be impossible for this to appear before the admin user error, because the GUI won't even start if that error appears.

You put "Superior" in the title. So, no.

How does TWR and delta V planning factor in to such usage? Does the workspace system provide a way to know whether your three separate craft will be able to lift off the pad once you marry them up, other than doing the math in your head or on paper?

So far Microsoft's online scanner seems a little smarter than the one they put on everyone's PC. (If you ignore the fact that this gigantic table can't be shrunken down to be more readable, and that instead of an overall summary line, we have to read "No malware detected" 28 times.)

No, CKAN releases are never compiled on a PC. An automated process builds them in a fresh Docker image. I've filed a request with Microsoft to get their busted scanner fixed. In the meantime you can tell Windows to allow this file, but the UI for that is about as terrible as the scanner that's raising this false positive, so you should go to Microsoft for help with it as their paying customer.

The CKAN client v1.34.4 "Niven" is released! Another small, mostly-bugfix release, including: Eastern hemispheric users had issues installing very recently updated mods "One or more errors occurred" during repo update Multi-hosted mods weren't falling back to the next URL if the first one failed Compatible versions popup was doing weird things to the max game version column Audit recommendations wasn't opening TSV/CSV export wasn't working Indicator links under the mod list to help users figure out why some mods may be hidden from view ... and a few more Many thanks to everyone who reported issues with v1.34.2! Full changelog available in the release notes: https://github.com/KSP-CKAN/CKAN/releases/tag/v1.34.4

That's true for absolute numbers, but less so for relative/comparative numbers (and "beat[ing it] to death" with repetition doesn't change that). If someone wants to argue that there were exactly 4000 people playing KSP2 at the peak on December 30 because that's what steamdb.info says, then obviously that's just silly, because it only reflects an unknown fraction of the true number. However, we have no reason to think a KSP1 player is more or less likely than a KSP2 player to launch via Steam, so those numbers probably give an accurate-enough picture of how many are playing each game in relative terms (~1.6 KSP2 players for each KSP1 player at peak, about 1-to-1 at trough). Similarly, there's no reason to assume the percentage of players who play via Steam varies over the course of the day or a week, so the trendlines probably reflect real changes in the size of the player base (down about 60% since the huge bump for 0.2.0.0's release). I would never argue that the player numbers establish that a game is popular or unpopular, but it would be really hard for them not to reflect big differences or changes in real world numbers.

Version 1.5.1 came out on 2018-10-17 and is still available in the "Beta" list on Steam. Anyone with concerns about this software "rotting" can try that out and see whether anything has broken yet after six years. The chances of that are low, not high. The libraries are bundled with the game itself (go take a look in the KSP_x64_Data\Managed folder) so they're not going to become unavailable. You'd have to wait for incompatibilities with the OS itself to crop up, which OS vendors try to avoid.

To me, this is an appropriate trade-off / design challenge. One set of incentives pulls you in one direction, and others pull you in the opposite direction, and going too far either way has risks and penalties, so the player has to find a balance rather than going all-out with one solution. It sounds like you're not happy with the options for expanding outwards, but all tanks support radial attachment, and if you want to use staging in such a design, there are radial decouplers. Since there are design trade-offs regarding width, the player has to carefully consider how wide is too wide. I find that a good way to handle that is to exploit the already-necessary scale difference between upper and lower stages. For example, here's my Exploration Mode Mun/Minmus lander: The radial tanks provide more than enough fuel to land and return without overly stretching the height. And it's still narrow enough that the (single-stage) launcher can get it to orbit without difficulties (with an undockable refill tank that makes up most of the fairing's height): A caution to anyone thinking of trying that design: leave the landing legs out to avoid bugs with phantom forces on switching craft.

The lows have, but the highs are still bouncing noticeably higher, including right now as I type this: It's an interesting pattern. I suppose it means that KSP2 is doing relatively better than KSP1 in the "peak" hours of Steam player activity? US versus rest of world? My excitement morphed to disappointment when I discovered this fraction was made from superscripts and subscripts. There's a single ⅔ character in unicode!

I'd call that a worse suggestion; I typically turn that feature off when it's an option, and even with it, scrolling a whole page is too much.

Doesn't that happen in the Resource Manager rather than the Parts Manager, though?

Reported Version: v0.2.0 (latest) | Mods: CustomFlags | Can replicate without mods? Yes OS: Win 10 | CPU: i7-3770K | GPU: GTX 1060 6GB | RAM: 32 GB Gather several pages of science research entries (I experienced this with a crewed craft that had landed a Science Jr on Mun and Minmus) Open the Research Inventory window Put the mouse cursor over the window Scroll the mouse wheel one unit downward The list of reports scrolls by a full page. This is surprising because in other applications that use the mouse wheel, the mouse wheel scrolls 1–3 lines. For example, try it right now in the web browser you're using to read this (in another tab if this page is too short). Multiple times now I have had the experience of wanting to find a specific research report in the inventory and missing it because I scrolled past it because of this. Suggestion: Make the mouse wheel scroll the window about half the height of one science research entry. Included Attachments:

Yes, that's correct. Yes. A higher orbit requires you to be going slower, so you'd have to burn more to capture up there. A higher orbit also doesn't add as much potential energy to your speed while you're falling inward, which by itself would decrease the magnitude of the capture burn relative to a lower one. But the two effects together still favor lower captures.

Whoa, I missed that change and thought we still needed BetterTimeWarp, but a quick trip to Minmus1.0 confirms the limit is gone! Do you remember what version of KSP1 dropped it? Maybe it was after the code was forked for KSP2 and they just haven't gotten around to considering it here yet. BTW, upvote here to support having the same freedom-to-warp in the sequel:

Only? I have no idea. But given that it has an upvote mechanism and that there's a weekly status report covering highly upvoted bug reports, it's probably the most promising way.