Wolf Baginski

Running a check with v1.5.1 You can still find it on Spacedock but it is getting old. See my comments above. It's tricky to fit engines and there's some fiddling to set up decouplers and staging, but it works as well as it ever did. Integrated Stack Decouplers is available for v1.5.1 and I think I should have installed it. But even without the extra delta-V from the interstage, I got sub-orbital. No sign of problems with the graphics or models.

OK, but does it make any difference to Mods? I see it's a part of a change in procedure involving releases, and while there's not much released for 1.5.0, is it worth worrying about?

Murphy Kerman's Law: If something can go wrong, there will be a mod for it.

I thought I'd check what plug-ins it used. I found these. Kerbal Actuators Deployable Engines B9 Part Switch B9 Part Switch has just had an update, and Deployable Engines is in the Kerbal Atomics package. Having latest versions of all three would be a good idea. I suppose the same can be said of Near Future Props, and I wouldn't bother added the included version of Module Manager. But will that be enough for reliable operation? I have a feeling I may have missed something.

I am not sure if this is a question, an answer, or a warning. I'm running Linux Mint 18.3 with Xfce, an Ubuntu derivative, and problems started after I installed KSP v1.4.4 Graphics settings can mess you up. My mouse pointer started showing in a different position on the screen to the point-of-click. The offset was consistent enough that I was eventually able to change the settings to a combination of matching the monitor pixel-dimensions and having full-screen on. It helped that it was essentially vertical, and you could see the active button light up, both ordinary menu screens and the setting screens. Since the problem persisted through a clean install, wiped the whole folder and replaced from the zip-file, it looks like something was being saved elsewhere, but I haven't been able to track down any changes with plausible timing. It couldn't be anything before today. It only affected KSP. The offset only affects the contents of the KSP window, not the close-window button provided by the OS. This was happening with an un-modded install, and could very well explain a problem I was having with a mod. Whether the mod triggered the problem, I am unsure, but since it persisted after a clean install that seems unlikely. (I know, it's not practical to test every Linux version and desktop that is current.)

Things have changed a lot since some of the answers to this sort of question that have popped up on Google. We have, for instance, 64-bit versions of the program, which means RAM limits are less of a problem. First, what are the problems? I don't recommend having less than 8GB RAM. This old machine I bought as an upgrade had 6GB, for arcane reasons, and that didn't need to Swap to HDD, but I have upgraded. 4GB may still be enough for an un-modded install, but 8GB gives you a margin. Remember the OS and whether you might need to run a web browser to look something up. KSP isn't bad for memory use. KSP is also pretty light on graphics. I'm still way behind the curve, but hardware prices are still dropping. I am using an nVidia 750 which is fine, but good luck finding a real one. Prices have dropped enough that the current nVidia 1050 is a plausible option for me. For what else I do the 750 is marginal, but it's OK What I have seen is that KSP does a huge amount of floating-point math in the CPU for the orbits. And a big craft with a lot of parts is the problem. The old data on this is that Unity didn't take advantage of multiple cores, it just maxed out a single core, and that was the bottleneck So can Unity genuinely use multiple CPU cores? If it doesn't, it makes current benchmark tests rather misleading.(Multiple cores was the answer, I remember being told, but some software still doesn't take advantage of it, and I know it's not always easy.) (Arcane reasons: most computers arrange RAM in two channels. This machine uses three, but works with two.)

This is one of those things where Hyper-Edit and MechJeb can be use without shouts of cheating. 1: Go into sandbox mode 2: use Hyper-edit to put the craft into a parking orbit 3: Use Mechjeb to find the minimum delta-V for the transfer to the target planet 4 Change orbit and repeat. Plot a graph of parking orbit against delta-V, find the minimum, that's the gate orbit. The delta-V for that orbit is what your booster needs. The delta-V for the transfer could be on the probe, or on a small booster. An option would be to have a small fuel margin and stage the booster on arrival at the target, you will be making a burn there. This sort of simulation is part of how RL rocket scientists plan missions. Personally, I have Hyper-edit installed, but I don't use it very much. I think it's OK for routine stuff like filling a fuel-station, after I have done it with a real mission.

A half-remembered point about node-specification. Some multi-node components use a different way of specifying node positions, putting them in the .mu file. An example would be the Engine Plates in the Making History set. I don't know where you would find documentation, and I am not sure it would get you out of having a separate docking port component because of the control-from-here setting.

Yes, that's the one. I was pleasantly surprised to discover it's still working with current KSP.

A quick check of the .cfg file suggests you could disable the sun-tracking, though there are some differences in the detail between something like the stock Gigantor and Nertea's panels. Also, the localisation system makes a copy and edit of a .cfg file a little more of a fiddle. For your own use, you don't need the localisation pointers in the name and description, just put in something useful to distinguish the panel from the others. I think I would have the English part-name as a comment, as the stock parts do. Anyway, for one of Nertea's deployable panels, it looks to be as simple as this: sunTracking = true Change the line to what one of the static panels uses. sunTracking = false Then you could deliver a neatly-packaged unit to your Mun-base, set it up, and extend the panels. Looking at the stock Gigantor, it points to the same code module, so I'd expect adding the above line to have the same effect. But there are other differences that might matter. My main computer is down, so I haven't tested this yet, but I am pretty confident.

This is something that is an obvious use for Tweakscale. The Tweakscale pack does have details of how to config something in its documentation file, and the PTD endcap would be the obvious part to use with that, if it doesn't already. I may be thinking of a different style of end-cap or blanking plate, usable with one of those multiway hubs (or I may be looking at a different PTD part). I find the localisation system can split the familiar name from the .cfg file, which wasn't helping. I've tended to use a docking port. The old-style multi-size ports that Captain Kipard produced are still working in 1.4.x KSP, and are what I use in such situations.

In the MOLE/Assets folder there are three texture for the "Corvette" that appear to be duplicated, in both .mbm and .dds format. Corvette.mbm CorvetteNormal.mbm CorvetteSpec.mbm (I found them when I was checking for large texture files, so there may be a few more.) I've been looking for a utility that lets me check and edit .mbm files, but no luck yet. If they're not duplicates, the naming is strange. Can I delete one set, and which one?

I did check on this. Linux and Mac are both Unix-style under the graphics. It's not for everyone, but I'll put this link here that explains things. I don't use the shell much, but it's there. Using the Mac terminal

It's a bit more work, but if you're using Linux you can use the "find" command to get a list of files above a certain size. Might work on a Mac command line too find $HOME/KSP_Linux* -size +9M There are a few mods which have used really huge texture files, but a 2k-resolution file comes out at about 5.6 Megabytes Quite a few seem to be .mbm files, which are an older graphics format that KSP was using, different to the more usual .dds format. Since KSP has an option in Settings, under Graphics, to use lower-res graphics, and the default is half-res, according to the Wiki, downscaling the graphics could pay off. The on-disk file size might be smaller than what is stored in RAM, and if the default half-res looks good enough for you, you might save as much as 80% of the RAM used for .dds files by downscaling and switching to full-res. Some models use .tga and .png still, which is easy to downscale. There are instructions here for getting an .mbm file into editable format, and it scares me. Yes, I know I use Linux. It still scares me. There are scattered mentions of tools which do the conversion but all the links I find are dead-ending. I hope I can find something for The GIMP but either .mbm is a rather old format used by some mobile phones, or KSP used something else. It does look rather as if the programming team are as bewildered as I am, since it is hanging around on a few old parts.

I can think of three mods which provide part/texture/fuel switching functions, plus the new stock support. They overlap a lot. Would is be possible to make a mod that, maybe with module manager patching, could give a single interface for this? I'm prompted by that Toolbar API mod that simplifies things a bit for mod writers. https://forum.kerbalspaceprogram.com/index.php?/topic/161857-141-toolbar-continued-common-api-for-draggableresizable-buttons-toolbar/& But it might be worth going a little bit further and doing at least some of the switching in the mod. On the other hand, just translating all the texture-switching to the stock function could make things easier. Is this possible? Would it be worth doing?

There's a gap between the one-kerbal capsule you start with and the later 3-kerbal capsule, and a Gemini-like 2-kerbal capsule is worth a look. There are several mods which can provide this. I have found that the M.O.L.E. set gives a wide range of options and works well, capsules, small space stations, and an intermediate booster size. Several mods give extra sizes of fuel tank, some with a larger diameter, some with just extra-long fuel tanks, one part rather than two to get the capacity. I think there are several different switcher mods, which is a minor annoyance. You might need three (that's my count, there could be another). Has anybody mentioned Module Manager? That's one of the essentials, nearly everything makes some use of it. Some mods are quite specialised. The QuizTechAeroPack is full of parts for the Mk2 fuselage, but if you don't want to try spaceplanes, why bother? Similarly, there are packs with lots of parts for space stations. Often, you don't really see anything from them until you get well up the tech tree, so there's no rush.

There are a few settings that help, such as one for texture sizes used. Not a mod as such, but I have sometimes used The GIMP to make a reduced-size version of a .dds file. I don't know whether that game setting saves any RAM, but dropping the file-size from 20MB to 4MB seems worthwhile for loading speed. My computer is pretty low-end by current standards, but I found that increasing RAM helps with a lot of stuff. With only 4GB it would often start paging to virtual memory, and that is a huge slowdown. Not always practical, I know, but there are utilities that show RAM usage, so it's not hard to check on. I think I may have a few too many mods in my Gamedata, but things such as parts only really slow things down when you use them.

I had a look at some stuff and, yes, that's what I found. The usual technical term I have seen for this sort of collider shape is "convex hull" (and I know I am picky about words and phrasing). You can make something quite complicated with multiple colliders, but it has a cost, memory and clock-cycles, and I have seen enough excessive detail, here for KSP and elsewhere, that it gets irritating. Marvellous models, but who will ever see the details in use? Elsewhere, I have used a game environment that had some tools in it for seeing this sort of complexity, getting a number for just how much work needs to be done to render an object, and I see a 20:1 range for visually similar items. I've never seen things getting that crazy here, and we each have pretty good control over what we have in KSP when we're running it. It's not like a multi-player online environment (and most don't allow user-created content anyway). Sometimes, a single implausibly big engine might be more fun than a realistic multi-engine rig in the style of a Falcon 9, because it's only one part, with a simpler-to-render mesh. It's a bit like the difference between the Snacks! life support mod and others. Anyway, I'm starting to ramble. But if KSP wasn't fun, would any of us be here now?

I am not sure that a collider for something like that engine should ever be more than a simple cylinder. The key point is this: "The collision mesh is required to be a convex solid (no concavities)." That's at https://wiki.kerbalspaceprogram.com/wiki/Part_Modelling_Guidelines#Collision_Mesh , a page which we're warned is out of date. I am sure I have seen more recent models with a collision mesh that conflicts with that description, maybe one of the Gemini-style capsules, but why bother with anything more complicated for this case? The collision mesh is for triggering earth-shattering kabooms, not for looking nice.

I haven't downloaded that mod, but the slightly-revised description did suggest it was something more like what @Nils277 has described. There are all sorts of slightly dubious flag images out there for KSP, and I've used a few that strict copyright enforcement would block. If a copyright-holder finds something, they have to react. Even if they think it's no big deal. I hope we can keep things gentle on this sort of issue. Anyway, I think my list of general warning-signs still holds, though I am a little embarrassed how trivial this instance is.

It was this one on Spacedock. https://spacedock.info/mod/1775/Geronimo Stilton When first posted there, there was less detail about just what it was.

I am not going to reiterate all the stuff you can find elsewhere about malicious hackers but I saw a new mod, a little while ago, that prompted me to prepare a special bargepole for the purpose of not touching it. This is a pretty safe place, with a bunch of great guys making mods, and a set of rules on licensing and other stuff that is a pretty reasonable deterrent on people with a motive to hide. But are there warning signs? This was on Spacedock, but I don't think that's relevant. Places such as Github, and specialised websites for a Mod, could be exploited, but without an account here, how would they be publicised? And that leads to the first test. Is there a forum thread backing up the Mod? I'll stick with Spacedock for the other tests, because you have a nice, neat, list of info. Test 2 (two parts): is there a picture, or any info about what the mod does (the title can be part of the info)? Spacedock has a pop-up text on the thumbnails, and the mod that prompted this at least has that. Test 3: have you seen the creator's name anywhere else? Everyone has to start sometime, but I'd expect a modder to have some trace here, even if they have never made a mod before.. Test 4: There's a list of acceptable license terms, and anything else should be a warning. It's not the place to be jokey. After that, you're getting into the general feel of things, and there are ways in which a mod might make you doubtful which can depend on things like native language: they're personal and unreliable. I have had many fraudulent phone calls from India, some well-known scams, that make me wary of the accent on an unexpected phone call, but there are far more relevant warning signs. And there's one big alarm bell left. Where's the source code? If there's no .dll, if it's just a set of parts, OK, but then you get into hard dependencies, so many mods need Module Manager, but that easily passes all the tests. Though if a mod includes a copy, I don't install that. If it's a mod you haven't heard of, you need to give that the same checks. I don't read source code, just as I don't read French, but not having the source code available is like telling me that La Marseillaise is a lullaby. There are environments elsewhere that have a lot of user-created content, and users who abuse the possibilities: some places we call them "griefers". It's a better fit to what I suspect I saw today than a bitcoin-mining hacker would be. I suspect I would have ended up with some intrusive graphics, inserted into KSP by some sniggering dweller in mom's basement. I could be wrong, but this time I am not taking the chance

I just had my Android tablet shut down on me with a 5% power warning, so it's not even rocket science... Thanks for the link to that Mod.

I have done a few longer-range expeditions, there seems to be a very small patch of another biome to the south of the KSC, but it can take a bit of finding. In one of my crazier moments I fitted an RTG to one and used it on the Mun. It seemed eminently sensible to explore with a nuclear-powered Land Rover. Either a trailer, or one of the larger 4wd vehicles would be better for long expeditions. There was the 1-tonne Land Rover, used by the British Army as a tractor for light artillery, which was also used in several real expeditions, but the Pinzgauer isn't very different, and it much more widely used. It's good to hear that it's still working, and I think the Firespitter plugin has now been updated.

I can think of a few mods which have parts that wouldn't line up so easily. Greenhouses, for instance. And early-game craft often don't have the extendable arrays of solar panels. So pointing the stack-axis at the sun (up-down in the VAB) just wouldn't work. It's questionable, cheat or not, but this is one situation where HyperEdit could make things a bit simpler. It has a function where you can alter the level of battery charge, and you could just move the slider to 100%. If it's going to recharge anyway, that at least saves time, and it's not so different from changing game speed. I mostly use HyperEdit during testing but, occasionally, I try to transmit data, the battery goes flat, and I lose all control until it gets charge back. If the solar panels are badly aligned, and something such as a SCANsat unit is running with even a low continuous power drain, the probe is dead. So, a related idea. A mod that stops a transmission at some very low charge level, rather than at 0%