sfhq

OK, that explains it. Is there an easy way to enable this for stock tanks or would that be a bad idea?

Hi there, I've been using Interstellar Fuel Switch for quite some time and can switch tank contents in the editor, but I cannot switch tank contents in flight (tested with an empty tank "Rockomax X200-32", currently set up for LF/OX). I wonder why. Unfortunately, I cannot remember if that ever worked (on past versions) or not. I'm on KSP v1.10.1 with these mods: The mod list is an export from CKAN. Versions are such that 1.10.1 is officially supported whereever possible. Some mods officially are for 1.9.x max., very few are for 1.8.x or 1.7.x max., but those (1.8.x and 1.7.x) should not affect tank parts. And the game is, aside from the "usual" memory leak problem, quite stable. I'm pretty advanced in the Community Tech Tree (available research items typically cost 1.000 science points or more), so I think the tech required should have been researched already, although I'm not so sure what exactly the requirements are. I do have Engineers on board, not sure if required. Does anyone have an idea what is going wrong? Anything known to be incompatible from the mod list? Or is there some obvious error on my part that I do not see? Is there a list of all conditions that need to be met? Thanks in advance for any help.

You are right, of course, but that doesn't help gamers on Windows and I just wanted to help those, being one of them myself, unfortunately. They have to survive somehow, unless they are willing to switch over to the *nix/Linux world. I myself am a huge Linux fan and I'm using it a lot personally and professionally, but still I can't get rid of Windows completely, it just doesn't work for me, neither at home nor at work. Not because Linux isn't good enough, but due to some circumstances that currently cannot be resolved in a way that I can toss Windows into the trash. But nevertheless, I *always* have a running Linux system within reach, so I can use Linux whenever it is the better choice. Aside from managing serveral servers, of which *most* are running Linux.

Sorry, that is something that most likely cannot be solved on KSP's forums.

KSP does not need Steam anyway. Not matter the source of the files. KSP has no DRM, not even the Steam release. But you sould not openly accuse someone of software piracy without any proof. There can be many reasons for older KSP versions. For example, only the Steam version does auto-update (if not disabled), but the KSP store version (which I have) never does. I have to upgrade manually. Which is perfectly fine for me, I don't buy on Steam when I have the choice to get it DRM-free from the manufacturer or stores like GOG.

Actually, strictly speaking, this is NOT Microsoft's fault (this time). KSP behaves very much "old style" here, trying to save data to its program installation folder structure. But it should not! There is a reason why Microsoft decided to "invent" UAC and stopping reagular write access to protected folders like C:\Program Files or C:\Windows. For many years, Microsoft has pointed out (correctly!), that user data is not supposed to go into the program installation folder, but into the user's AppData folder. Unfortunately, still, many software titles ignore this, especially games. This leads to people assigning blame to Microsoft, blame to software/game developers and such recommendations like "run it as an administrator" (which is very bad except may be for "first run" situations, where some additional setup steps may be required). To prevent such problems for all games, the first thing I do on a new PC is create C:\Games and install all games to this structure, including Steam (or a least, the Steam game library). Actually, you can name it anything you want and even put it on other drives than C:, the only thing important is, that it is a folder you created by yourself, one that was not created and UAC-protected by Windows. Windows will not UAC-protect folders you created yourself. Following this advice, you'll never have the need to use "run as administrator" every time (even if the game manufacturer tells you otherwise) and the games are able to write into their own folders, even if they should not. Therefore, less risk for malware, since you're no longer using elevated user rights (administrator access). I hope this makes sense to you and helps.

Just a wild guess, but when moving from one version to the next, did you make sure that the GameData folder includes the folder "Squad" with the original (stock) parts and the DLC folders (SquadExpansion) (if you are using them), from the current (new) KSP version? It is easy to get trapped when moving GameData from one KSP install to another, assuming it's just for the mods. It also contains parts of the original game.

This is bugging me as well, massively. The tricks to circumvent this bug do work, but it still is barely acceptable, and you have to repeat them for every new resource transfer, or you might have transfers stuck or even happening between parts that aren't even selected. Hovering over the resource panel makes KSP highlight all tanks carrying the selected resource on screen temporarily, which makes KSP very slow when you are transferring fuel from a mining/refining vessel to a large station with lots of tanks. I cannot understand why this bug is categorized as low priority, it should be high, to be fixed ASAP.

I suggest to skip 16 GB and go for at least 32 GB, if possible. My modded KSP 1.10.2 install easily consumes up to 16 GB at start-up. It tends to consume more when running for a while with several mods and a fat savegame. (several "flights" (including satellites, stations and ground bases) active) Please note the following difference: There is current memory usage (which can go up and down quite rapidly) and there is the commit size. The last one is the higher one and is revelant if you want to prevent disk swapping. It is the memory that KSP pre-reserves in case it is needed, so it doesn't run out of memory if it isn't available when the request for it finally comes (which would lead to an instant OOM crash back to desktop). So even if current consumption (1st value) is lower, the system needs to make sure (that is, to actually reserve) the higher value when KSP asks for this reservation at launch or somewhere during the game (yes, this also can increase, but rarely decreases in-game). So to prevent swapping, you need to have physical RAM for Windows, all background tasks and this very high value from KSP. If you cannot avoid swapping to disk, it can help greatly if your system drive (where Windows and usually also pagefile.sys resides) is a fast SSD drive instead of a mechanical hard disk. Not to mention that an SSD generally makes the whole system a lot faster, even if your games still are on a separate, classic drive.

I agree completely. I myself was quite disappointed with v1.3 of KSP, especially because of the very limited number of languages they added. IMHO, they missed several important ones. For example, I've got some friends who'd like to try out KSP, but they lack the required knowledge of English. There are a lot of KSP players here and potentially even a lot more - if they just supported German. Sadley, they don't. For me, it doesn't make any difference - so I have nothing to gain with v1.3, but a lot to loose (compatiibility, at least until all mods have been ported to it). I really hoped they'd work on something else for v1.3, but just some languages... :-( sfhq/Mark

Hi again, you're really doing a great job at supporting RP-0. Since my last reply, I've been able to add some interesting of the "suggested" mods and KSP is still running. Regarding CKAN, I have to revoke my previous statement: CKAN DOES proper version checking and is QUITE ABLE to install an older version if needed by KSP. But it depends on the CORRECT METADATA to be provided by the package author. I just installed some stuff using CKAN again and I watched for that metadata information. If multiple mod versions are included in the metadata with different values of supported KSP versions, CKAN usually picks the right mod version, NOT always just the latest. CKAN knows of 3 states: ideal version, compatible version, incompatible version, color-coded in the metadata display list. So I guess, there is at least one, maybe more mods required by RP-0 that do not carry along the correct metadata information. This obviously is why the CKAN mod installation crashes KSP afterwards. Just thought you should know. sfhq/Mark

Hi, it took quite a while and wasn't fun at all, but after a lot of searching, I managed to downgrade all mods including binaries (.dll files) to a version compatible with KSP v1.2.2. It now launches with all requirements of RP-0. To make it even more confusing, KSP version requirements displayed by CKAN do not always match the real requirements by the mods. So I had to look at all this information manually and some files were quite hard to find. I very much like content availible at spacedock.info, as they also offer all old versions, this greatly helps. Some mod authors also keep (at least some) older versions availible, but not all. Thanks to Phineas Freak and TheRagingIrishman for all attempts at helping me, it's much appreciated. sfhq/Mark

Oh-oh. I always assumed that CKAN watches for dependencies as carefully as the original CPAN (Comprehensive Perl Archive Network, name-giver to CKAN) does, including the required versions, but obviously, it doesn't. Looking at the CKAN main sceen, about the half of the mods are already compiled for KSP v1.3.x. So I guess I have to downgrade all of them? I already downgraded Magico's stuff (I took his v1.2.2 compatible versions from another v1.2.2 mod installation) and CBK, but I'm still getting these crashes. Slightly crestfallen sfhq/Mark

Thanks for the prompt reply, I was quite sure that the stock install was OK, but in fact, the Squad folder inside GameData folder wasn't. So I fixed that with fresh files from ksp-win64-1.2.2.zip (downloaded from Squad/KSP store), tested this "vanilla-style" install and started all over with the mods, once again, only with the minimum required components. The loading process takes much more time now and there are no more error messages, but then, the game crashes back to desktop, right as before. UPDATED LOG FILE (2017-08-03_171310) While I have quite a good understanding of KSP itself, checking modded installs isn't my area of expertise. Plus, I never had crash issues with previous modded installs (KSP-with-TACLS / KSP-with-Kerbalism), they all work fine with v1.2.2. I really hope this RP-0 issue can be resolved, now that GameData/Squad is ok. I'm quite eager to try this out. sfhq / Mark

Hi rsparkyc, hi to everyone else! Being quite happy that there's now a way to run RP-0 on KSP v1.2.2, I created an additional copy of KSP just for RP-0. First I completely cleaned the install from everything that might interfere, so only the content of a fresh install remained. Then I followed Scott Manley's most recent video tutorial to install RP-0. Being careful, I skipped everything that is not mandatory for the installation, so I installed RP-0 using CKAN without any additional suggestions (but I took a screenshot there, so I can add those later) and scatterer v0.0300 from the scatterer download site as shown by Scott. When launching KSP v1.2.2 (64bit on Windows), it takes quite some time to load, but that's ok. Then module manager reports one error: 1 error related to GameData/RP-0/PartHacks.cfg The next moment, KSP crashes and returns me to the desktop. In fact, that happens so fast I couldn't read that error message the first time, I had to do a quick screen capture to read it and copy it down here. Log files Any ideas? Thanks a lot in advance! Yours sfhq / Mark