Corax

Absolutely up to you, but if I were in that place, I'd set aside the time and do a proper update, even if it cannot happen right away and may take longer initially; quick-and-dirty replacing one special character with another ultimately sounds like a recipe for failure. 'Hash' and 'at' have special meanings as well, and you'd have to test to see if they do have any side effects, which will need to be done again whenever a more sophisticated solution presents itself. It's not like the mod is completely unusable in its current state, it works fine even in 1.9 for the most part, with the exception of the caveats noted before. Maybe put a warning in the OP, and do a proper update/rewrite whenever you feel like it.

Oh damn, that is a little annoying. Yeah perhaps letters would be cleaner. Are you still active on this? I just found your Project Manager, and I have to agree, the asterisk convention causes a lot of issues. What leomike said, and also at least when using Katateochi's Craft Manager, the vessel preview thumbnails are not displayed correctly. Since the asterisk is also used as a wildcard character in regular expressions and other search patterns across multiple operating systems, I don't even want to start thinking about other side effects... similar can be said for the tilde character, which at least on unix-ish systems (Linux, probably MacOS too) also has special significance. It's not a simple problem to solve if one wants to avoid characters with special meanings, since almost everything other than letters and digits is used somewhere or other... Maybe it would just be best to interpret the first single group of non-whitespace characters after the closing bracket as the type indicator, if it's a number, use numbers starting from zero or one respectively or simply begin counting up from there, if it is a Latin single uppercase letter, use alphabetic letters, and use Roman numerals with single Latin lowercase letters? That could even allow for recognizing words like "Alpha" or "Able", or other alphabets like Cyrillic or Arabic if you were to include such schemes one day. Another consideration, in combination with above, would be to interpret the last character inside the tag as the type indicator, and fall back to regular numbering if it can't be interpreted as a valid indicator. I'd already have to rename a lot of my craft files, but hey, would do so in a blink. Until then I'll just have to stick with conventional numbering, at least the roman numbers are currently unusable for me.

Link please, if possible? Always kudos for Linux ; ) I don't know about either Mint or xviewer, but maybe I can interest you in geeqie, which was once gqview, is one of the better image viewers out there IMO, is in daily use on my Gentoo box, and has no issues opening this file.

That's the point, without Kerbalism, there is significant temperature fluctuation. Also, without Kerbalism, you can measure the thermal effects of running rocket engines on adjacent parts, as well as insolation, which you can't with Kerbalism. Admittedly the last time I did test either was with 1.7.3 and whatever version of Kerbalism was then current, but it doesn't seem that aspect has changed since then. PS.: Actually I'm not entirely certain whether it's Kerbalism's science, radiation, or whatever other component(s) may be responsible for that. PPS.: Regarding fluctuation and 6hr days, true, but currently it fluctuates by about 0.1°, I'd expect a bit more than that even with shorter sunlight times.

Yup, those definitely look more like what one might expect in the next few decades, from ESA or any other player. Except SpaceX maybe : )

I haven't looked closer into your config yet, but it reminded me of some observations I made a while ago. After updating my Kerbalism config to show Sievert instead of Rad (have never used Rad before, so I didn't notice initially), the background radiation on Kerbin is reported as 4µSv/h, an order of magnitude higher than on Earth. I don't know if that is an oversight, or based on the closer distance of Kerbin to its sun–although I'd then reckon to be the (smaller) sun's output being less as well. According to Wikipedia (of course not Kerbin, not Kerbol, not Kerbals), Using 2400µSv/(365*24h), I'd expect 0.27µSv (or maybe 0.4) as opposed to 4.0. Additionally, the average temperature at KSC is about 287-something Kelvin, which for an equatorial site seems awfully low. And it doesn't fluctuate much during day and night, if at all.

Since it's CC-BY, and I happened to have a local copy, greening-galaxy-kerbalgirl_base_2.xcf Enjoy ; ) EDIT: Note that the sha256sums differ, but AFAICT the file is the same; I probably did some layer visibility changes and didn't think to make a copy beforehand.

You probably already have, but since you mentioned it, the most obvious thing to try diagnosing would be to start with a new, unedited save...

If I may, I'd like to suggest a feature: There are a few dialogue boxes that would benefit from displaying more information, namely the confirmation dialogue for "Scrap Vehicle", and the crew selection dialogue when you "Launch Vehicle": Both would be much more comprehensive–and less prone to user error ; ) –if they would display the name of the craft you are going to scrap or launch, respectively. Also, if the crew selection dialogue could display which site the vehicle is going to be launched from, that would be immensely helpful too. Nothing pressing, but would be awesome to have that additional info. PS.: Another thing that just occurred to me that might make for an interesting challenge: Would it be possible to block the functionality of buildings while they are being upgraded? To be precise, the KSC level upgrades, not KCT upgrade points. It seems strange from an immersion standpoint that I can build new vessels, and even more so conduct difficult scientific research, at full speed while construction workers are busy tearing down and rebuilding the place... Mainly VAB, SPH, and R&D, but the others might benefit from that, too. Since craft construction as well as research speed are already tied to KCT building upgrades, it might be "as simple" (haha) as temporarily masking all invested upgrade points until the upgrade is finished. Most difficult I would imagine would be how to handle the effects on Mission Control, if one has contracts running, and Administration with active strategies–on the other hand, it might be sufficient to simply block access to it so one cannot accept new contracts, while still being able to complete ones that were previously accepted.

I'd have been surprised if it had been, but then, I don't know all and everything ESA is planning, even if it is only as a concept study. They should get going on it though–NASA will need more than just a service module to "land the first woman and next man by 2024"... ; ) EDIT: Whoops, ninja'd... sorry @Bling90 didn't see your post before. Still, do you have a link to the ESA article? Might still be available on some archive site...

Looks interesting–care to share your source? Preferably a link to an ESA site, or at least somewhere to find more information on this concept? I'm certain well has a life outside of KSP modding, and KNES is in a very complete state. In dubio pro reo... probably nuances lost in translation

Good advice here, with the possible exception of KJR. I haven't used it, ever, and have not felt the need to, also ever. Keeping mass down is really important, thankfully you can adjust at least the wing parts and control surfaces to more useful numbers. IIRC I was tuning them down to 0.2 or even lower–it's been a while since I used FAR, mostly because it never felt quite stable enough ever since @ferram4 went silent. Also, I wouldn't consider 80m/s particularly "slow", that's still ~290km/h. A slow plane in my book is somewhere up to maybe 50m/s, the real life Fi-156 (an exceptionally slow flyer) would stall around 50km/h, that's ~15m/s. Haven't managed to design something like that in FAR myself though. Disclaimer: I'm neither a pilot nor an aerodynamicist. Also, full ack on wheels and ground-based physics in general. Consecutively getting worse with each iteration, I really wonder what's going on there in Unity, or KSP, or Squad?

I don't think I follow your reasoning there–how can they be more related to space operations than other RCS? I would argue that the main use case for any RCS, stock or otherwise, MP or LFO, is space use, not atmospheric use. Because your parts are more efficient than essentially all other RCS parts that are either stock or balanced against stock, they make those parts insignificant to the point of obsolescence. Anyway, your mod, your rules ; ) –as I said, I'm fine with adjusting them on my end, but maybe you'd want to reconsider your balancing. Either way, I really appreciate the work you put into it.

I saw both of your posts, and you did not mention in your second one that you tested it with EYS only. that doesn't sound like it's a stock+EYS issue but an interaction of several other mods, so I provided some additional data points, just in case you hadn't seen them. hth, peace, stay healthy. Corax out.

If you read back a few posts, I had the exact same issue–applying suits in the astronaut complex was not carrying over to the outside of it, in combination with Texture Replacer. What did work was changing the suits in the TR window, which carried over to the astronaut complex and flight scenes, and is "sticky", at least for me. I did not pursue the issue any deeper since for me that workaround was (and is) good enough. The reason I'm bringing this up is because you say you "have a lot of mods installed", so maybe TR is one of them, and even if it is not, it might help narrow down which mods are conflicting here.

Seeing the issue has already been reported by TrueMetis, here is the offending part of the patch: @PART[DM-SphericalTank-125-70,DM-SphericalTank-125-140,DM-SphericalTank-125-111,DM-SphericalTank-125-88,DM-SphericalTank-125-55]:NEEDS[B9PartSwitch,Kerbalism,DaMichel/SphericalTanks]:AFTER[SphericalTanks] { @MODULE[ModuleB9PartSwitch]:HAS[#moduleID[SphericalTankFuelSwitch] { ':HAS[#moduleID[SphericalTankFuelSwitch]' is missing its closing ']' bracket Sorry for (probably, can't even preview ATM) lousy formatting, the lovely InvisionForum software is acting weird again...

That is actually a good point–I never bothered to see whether (Mini)AVC might get installed along with FF, since my launch script automatically deletes any and all instances of MiniAVC automatically, and has been doing so successfully for the last few years, so it didn't even occur to me that there might be something going on with it. I mean, people even write mods dedicated to get rid of it (kudos to them, although it's something I never fully understood since a simple $ find can do the same job reliably, and without the need for yet another mod). Glad you figured it out for your install and got it working, and thanks for reporting your findings. FF is one of the mods I consider an essential part of my KSP experience.

It's mostly that i'm already playing a planet pack, and I don't know how to make multiple installs Fair enough. Regarding multiple installs, I simply copy the entire KSP directory to a new name, and create a symlink that points to the install I want to use, e.g. I have a directory KSP_linux-1.9.1, and correspondingly the same for older versions. Then I create a symlink named 'KSP' that points to the version I want to use ($ ln -s KSP_linux-1.9.1 KSP), and simply call $ KSP/KSP.x86_64 (could be from a shell script, or a desktop file). Useful to have a KSP_xyz_vanilla around that only contains the most basic settings, and optionally DLC, that you can simply copy for a fresh install, eg. for evaluating mods before you commit to them, or testing specific things. Thus the way I launch KSP never needs to change, only the link points to different instances. Does too : ) $ mono ckan.exe It needs Mono of course, but your distribution should provide that if it isn't already installed. hth

Are there any issues with JNSQ on Linux? I haven't tried yet (currently on 1.9, so no Kopernicus yet), but AFAICT at least previous releases of Kopernicus didn't discriminate which OS you were on. I've been running KSP on Linux since way before when, and the only mods that usually don't work are things like Scatterer that specifically target DirectX, and/or supply shaders, or rather don't, for specific operating systems/graphics hardware. Not saying Scatterer does or doesn't work, it's been years since I last looked into that one.

From what I can tell, you can only access the KK functions from "in flight", i.e. you need to have a craft somewhere in the vicinity, be in control of it; then click on the building and you should be presented with its menu.

Exactly. This isn't about the mod working for me, but letting reaction_wheel know that this mod can indeed work with 1.9. I don't know the way he used to install it, but (again, only reporting what worked for me) it worked flawlessly via CKAN, after I set KSP-1.8 as compatible (Settings -> Compatible KSP versions). Another way of installing via CKAN would be via the right-hand side "Versions" tab and selecting specifically Final Frontier 1.8.1-3479; that way, CKAN doesn't show any other mods as compatible. Seeing that FF doesn't have any dependencies, it might be worth simply trying a clean install, manually or using CKAN... EDIT: PS.: You suggested to "See the link in my signature" which without doubt is helpful, but again, just to let you know, I don't see anybody's signatures in this forum, so I can only assume there are others that can't see your link either.

Thanks, I hadn't seen that. However, deleting the original installation and installing kalmor's instead didn't make a difference for me. The exceptions are still there flooding the log, and none of the vessels and debris in orbit (previously and newly launched) showed any signs of orbital decay.

See the link in my sig block below for some guidance on problem reporting. Posting a link to your log file would be worth a try so we can see what might be going on. FF is not currently listed as compatible with 1.9+. Just FYI, while FF is not listed as compatible, I am using it in 1.9.1 and have had no issues regarding FF. The stock toolbar icon is there, and my crew get their ribbons awarded as expected.

It doesn't, at least not out of the box. Disregard, I have spoken too soon. After checking the first post, it seems CKAN only lists an even older version of OrbitalDecay. Installing manually from the Github link in the OP, the corresponding dependency, as mentioned there too, and making sure ORBIT_DRIFT_COMPENSATION is set to false, KSP loads and runs. Watching for a while, there does not appear to be any actual change in orbital parameters though, and OD throws reams of exceptions. At least it does not block, if that does count for anything. I have not been using OD before, so if anybody with experience with this mod could weigh in with their observations, that would certainly help clear up any open questions. Old inaccurate stuff: EDIT: PS.: It took me all of about five minutes to copy a clean KSP install, fire up CKAN to install only OrbitalDecay+ModuleManager, and launch (and shoot down) KSP. Maybe the next person asking could instead do at least this simple test themselves and report their findings... that goes for each and every mod, not only this one. EDIT2: Caveat: DO read the original post, and compare what's stated there versus what CKAN tells you. Sometimes they differ, and by a large margin. Also, that makes your test cycle take quite a bit longer, but it's definitely worth it. "Human decision required"–Moonbase Alpha Central Computer

Isn't it obvious then that it is a controversial idea. I can get behind adding content that makes Kerbin and other places appear more interesting, like cities, for example. But I still think having places appear populated works just as well (or rather better) without imposing artificial borders and ideologies, and it might even give food for thought to some to see a world that can work without nations and wars.