Anaxagoras

bizzehdee, glad to hear you'd already been working on this! and best wishes with finding a solution for the images. Still seems like a full dump would be super easy for whoever had admin with take-two to create. The MediaWiki installation also seems to be rather out of date, e.g. won't support any animated or video formats besides GIF. (Yes, it makes sense to not want to host much video, but the few animated GIFs on the wiki are 10x bigger and worse quality than they'd be if they were in a better format. ) If people ended up getting paid hosting for anything else, e.g. a forum, the wiki traffic is presumably small enough one could use the same account without extra cost. I guess wiki.gg seems to be the favored free / ad driven wiki farm these days, sounds much better than e.g. Fandom.

Given that people are talking about archival / migration / etc for the forums in case this site is dropped, I wondered if plans are underway to also do so for the wiki. Should be simpler than fora, but unlike Wikipedia etc I don't see that dumps are easy to find for the KSP wiki. Definitely advantages to having a dump rather than a scrape.

The wiki includes some large unwieldy animated GIF files, and doesn't seem capable of handling them well. These days there should be better options. I noticed this because the article for the Stamp-O-Tron Ground Anchor has a big empty box. Apparently it's been that way for two years. The person who tried to illustrate the less-intuitive way this part is used uploaded a 7.3 MB GIF, and apparently didn't realize that MediaWiki can't create a "thumb" sized version of large animated GIFs. Most MediaWiki installations these days would allow replacing GIFs with a vastly more efficient video format e.g. WebM . But the KSP wiki doesn't have a video extension installed (and doesn't allow uploading any video format file). The wiki does allow uploading WebP files, and browsers have all supported animated WebP since 2020. So I thought I could fix the Stamp-O-Tron article by uploading a correctly-sized animated .webp. But the wiki doesn't seem to recognize that WebP is an image format; doing [[File:foo.webp]] etc just inserts a link to the file rather than including it as an image on the page. I haven't yet tried seeing whether the wiki correctly handles a static WebP image; my guess is that it doesn't, and that accepting WebP files for upload is currently useless. I can tell the Wiki hasn't seen a lot of admin maintenance in a while - for instance, one giveaway is the boxes that continue to claim uploading files is broken, though it, must have been working for years. I can tell I shouldn't expect miracles. But I wonder whether the WebP issue might not be a difficult fix.

I'm not using a proxy or anything. But whether something was fixed, or just by waiting about a day, or whatever, it seems to be resolved for now.

I've been hit with the "Error 1015 You are being rate limited - The owner of this website has banned you temporarily from accessing this website." Can't reach either the wiki or the forum. I had been editing a couple articles on the wiki and using it more than average, but quite clearly not anything like a DOS or a crawler / web scraper or anything. The error was "resolved" overnight, but came back after loading just a couple pages today; I'm posting this from a phone with another IP. Anything that can be done about this?

Thanks everyone for your input so far! I've been playing stock but this may be what pushes me to try a mod for the first time. I suspected people were tolerating lower TWR than the .3 I was looking at, but was a bit surprised to find the consensus is close to half that. Haven't gotten to launching anything yet; I've been busy with life, and still have a couple other missions to finish before I do this contract. Would still be interested in seeing other designs if anyone would like to show something off. While cobbling together the drafts above I did have the thought that, given NERVs' ISP advantage and the countervailing fact that you can get >33x the thrust of a NERV for 3x the weight, there was room for designs that relied on NERVs for most of the dV but relied on LF+OX engines for brief thrust at key moments; it's interesting to see a design that did just that.

Wondering if this is a bug others are seeing or if it's just me: Around half of the time or more, enabling crossfeed on SRB's decouplers in the VAB reduces the SRB's displayed burn times and dV. For instance, a Thumper's displayed burn time drops from 42s to 33s. This doesn't appear to change the way the rocket actually behaves in flight; the boosters still burn for their appointed time. But it makes a mess of trying to design the rocket accurately. (It took me a good while to realize this was even possible, that you could attach liquid fuel tanks to your SRBs and enable crossfeed and the fuel would actually flow through the SRB, giving a half-asparagus effect. Drop tanks without the extra drag and without the cost of extra decouplers, even without having to run any fuel lines. Works well if you can time it so the tanks are empty right about when the SRBs flame out. This displayed burn time issue makes it a little less convenient to figure how much fuel to put there, as well as throwing off the overall dV calculation.)

Anyone care to share their designs or thoughts on nuclear tugs? (I found some old forum threads where people linked images of their tugs, but image links were dead. Some of the ones I found on KerbalX were clearly for show / concept art rather than for in-game practicality.) Background: I'm new to KSP; in sandbox mode I've landed on Mun and Minmus and orbited Duna, but I'm playing career mode now and haven't yet progressed beyond orbiting the Mun. I hadn't thought I'd be in a position to research the nuclear tech anytime soon, but just got offered a contract to test the NERV on escape trajectory from the Mun, plus a contract to put a station in Mun orbit. Seems like a good opportunity to put the two together and then have the tug available in LKO. But I was scratching my head over what'd be a nice design. One issue is the lack of size large LF-only tanks. The Mk1 tank is cost-effective, but a vertical stack of those is unwieldy at >3x the height things would be with size large. I don't have any of the spaceplane tech yet, so Mk3 tanks are out for this contract. Similarly, the stack bi/tri/quad adapters are out. I could use the bi- or tri-couplers: Oddly, counter to the surface area to volume scaling relation, Mk0 tanks have the best mass ratio, 11. Mk1 are 9, and Mk2/3 all ~8. So one can get a little more dV by clustering small tanks. Clustering Mk0 around a central Mk1 conveniently equals size large, or one can use radial Mk1: But radial Mk0 leads to part count explosion (8 Mk0 = 1 Mk1) and inconvenience having to refuel all of them. Radial Mk1 is either very wide or involves part clipping. And if you do clip them inwards, it can be problematic to clip them all the way in to fit flush within 2.5m, as then whatever they're attached to will be fully occluded (so e.g. if it's a tank it cannot be refueled). There's also navigating the TWR tradeoff. Station parts can be heavy enough that the fuel savings of nuclear make a difference even for Mun/Minmus trips, but seems like it needs more than one NERV to make reasonable burns. The above drafts with 3xNERV have just over 2000 m/s of dV when hauling a 36t Jumbo-64 tank, at 0.3 TWR. I'd be interested to hear what others have done.

I had long thought KSP sounded intriguing, but didn't get to trying it, and after announcements I thought, "well now I might as well wait for KSP2. " But I heard it was having a rough launch, and reconsidered that a bit. And then someone I know whose kid is really into space was asking for ideas; I gave him a copy of KSP1, then thought "I should check it out myself." Got hooked. In Sandbox mode I've landed on Minmus and Mun and orbited Duna. In Career mode I am finding it harder to avoid being perfectionist; the time and budget limits really aren't severe and I should be optimizing a bit more for fun rather than for in-game time or budget. Have a few simultaneous tourist flyby flights going while waiting for my first Munar orbiter to catch all the EVA reports on his polar orbit and return. What are some of your best tips for "relax, have fun, and learn to git gud, rather than obsessing over stuff that doesn't efficiently contribute to those goals"?

Ended up launching this as is, a few days ago. Have already thought of a couple things I could have done differently, but this'll do for now. And I realized that if it really matters later on, I could change some things about port configuration with EVA construction later on. (Changing the location of a docking port on a real station in space would be rather difficult!) I left it in very low parking orbit and moved on to other things for now. I intend to fire the engine again and raise it, but I haven't decided the altitude. In case I do end up with several non-trivial ships docking here at once, I do want to have it over the 160km procedural terrain rendering cutoff for performance reasons. Maybe 240km for warp purposes? And that is more of a "gateway orbit."

Again, the idea was that the port on the top would be a good place to dock a large craft, the other standard docking ports would be good for more normal ships, and the Jr. ports would give the option of having something like a tiny satellite service ship and a tiny Minmus ship. To say more about why I didn't just launch this after those fixes: Suppose, at some point in the future, after I've reached the tech for Sr. docking ports and the HubMax, I add those by EVA construction and start adding stuff. Then I might end up with something like this monstrosity. Please excuse the somewhat nonsensical additions; my point here is the now-largely-useless standard size docking port placement on the top piece which is the original station. The things I can do about this: Just don't bother with thinking of future expansion. Launch as is, and if I really want new features in a station that far ahead in the game, just construct another station. I think I'd just do this, without trying to get more advice, if I didn't also see this as an opportunity to learn something from this effort. Design any expansion to give the docking ports on the original a lot more room so they aren't useless. Put some big extension between the old station and the hub. Ignore the issue. If an expansion blocks old docking ports, it can compensate by having more ports in a better position. Think of a better port placement to accommodate both near-term and post-expansion docking.

Thanks for the feedback! I just now got back to this after traveling. I've removed the RCS thrusters. If I ever were to expand (adding a Sr port to the bottom via EVA construction after I've reached that point in the tech tree), I guess I should use a tug rather than having RCS on station parts. I switched to the Jumbo-64 fuel tank and added a SEQ-24 storage unit, which gave me more room to space out my solar panels and the two rings of docking ports. I've removed some things I realized were redundant: no need for radial attachment points for the ports, standard-size docking ports already have lights, etc. I can add more batteries, but I thought the Z-1K seemed like enough, given that the reaction wheel and probe core are the only consumers of power here. This will go in medium-low Kerbin orbit, so darkness will last a dozen minutes or so, during which the probe core would consume less than 20e out of 1000e. I normally do use the non-retractable panels. But as you mention, breaking panels is a concern for docking, and I think the retractable panels will let me play it safe when docking something unwieldy. The extra 0.028 tons seems relatively negligible in this instance. I certainly don't anticipate having 9 things docked here anytime soon. But I thought that early on, the rings of four ports could be nice for reducing approaching vehicles' need to maneuver to another side of the station to get a port, and maybe some of that added capacity might be helpful in the late game. That said, the number, type, and placement of docking ports is the thing I'm still most unsure of here. I had thought that a little Minmus vessel, or a little 1 engineer craft for satellite repair/refurb missions, could dock here, and might want the Jr rather than standard port. Maybe that's not actually a good use case? If I don't dock any Jr vessels here then yes, it makes sense to remove that ring.

First time playing KSP, have done some things in sandbox. Doing career mode now, and in this game I've orbited but not landed on the Mun. There's a contract available for putting a station with five kerbal capacity in Kerbin orbit. I probably won't ever get into extra fancy station-building, and though I've done the docking tutorial I'm not comfortable with it yet. But it seemed like if putting something in orbit could be marginally useful sometime in the future, getting paid to do it now may be worthwhile. Could I get some feedback on this craft? Especially any gotchas that I should fix so this could be useful later on? For instance, is this OK for docking port placement, reaction wheels, and RCS? Is it worth researching to get a probe core on here that can do normal hold, for getting it lined up right esp after future docking? I guess in other circumstances, doing separate modules for habitation, fuel, etc could be worthwhile. But since I'm not really comfortable with docking, and since it'll be a good while before I can research Sr. docking ports, the multi-point connector, etc., I'm making this kind of a basic do-it-all. (Except no science lab etc, since this will be LKO.) I've thrown a bunch of spare parts, repair kits, etc in inventory, largely thinking of "repair satellite/attach a part" missions. The decoupler by the main engine is in case, when I do get the Sr. docking port, I end up deciding I'd like to put a large docking port there in EVA construction.